<HTML>
<HEAD>
<title> rel4.0 </title>
</HEAD>
<BODY  bgcolor="#ffffff"  text="#000000">

<center>
<h1> rel4.0 </h1>
</center>

Date:     Mon, 6 Nov 89 22:50:11 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  CAD interchange formats, BRL-CAD, IGES, MEDUSSA, ...

<p>
I found this message on COMP.GRAPHCIS.  Attached is my reply, for those
of you who don't read netnews.
	Best,
	 -Mike

<p>
----- Forwarded message # 1:

<p>
From: Bill Kish &lt;kish@porthos.rutgers.edu&gt;
Newsgroups: comp.graphics
Subject: CAD interchange formats, BRL-CAD, IGES, MEDUSSA, ...
Date: 3 Nov 89 14:36:18 GMT

<p>

<p>
I'm trying to take a CAD application which is currently maintained by
the MEDUSSA CAD system and convert it into a format which the BRL-CAD
system understands.  I'm told that MEDUSSA knows how to translate from
its own internal representation format into IGES, but apparently the
BRL-CAD system does not know how to read in a file in IGES format. I'm
new to the BRL-CAD system and to CAD systems in general, so I'm hoping
that I'm just not looking in the right place.
	I also know people who wish to take PATRAN output and be able
to take advantage of the rendering capabilities of the BRL-CAD system,
but here again, it would seem that some sort of conversion utility
either has to be written or acquired.
	I can't believe I'm the first person to be in this situation,
so I thought posting to the net would be a good idea before I think in
terms of developing my own utilities.  Is there another newsgroup
specifically for CAD related issues ? I rarely if ever see CAD related
questions in comp.graphics.

<p>
Thanks,
Bill Kish

<p>
kish@jove.rutgers.edu

<p>
----- Forwarded message # 2:

<p>
From:  Mike@BRL.MIL
Subject: Re: CAD interchange formats, BRL-CAD, IGES, MEDUSSA, ...
Newsgroups: comp.graphics
Keywords: cad, geometry, interchange, format

<p>

<p>
Bill Kish  &lt;kish@porthos.rutgers.edu&gt; wrote:

<p>
   I'm trying to take a CAD application which is currently maintained by
   the MEDUSSA CAD system and convert it into a format which the BRL-CAD
   system understands.  I'm told that MEDUSSA knows how to translate from
   its own internal representation format into IGES, but apparently the
   BRL-CAD system does not know how to read in a file in IGES format. I'm
   new to the BRL-CAD system and to CAD systems in general, so I'm hoping
   that I'm just not looking in the right place.

<p>
There are several levels of answer to this question.  First, questions
about the BRL-CAD Package are generally best addressed to  &lt; CAD @ BRL.MIL &gt;,
which is the list were users and developers of this software interact.

<p>
There is a deeper issue here that I though would be worthwhile
addressing for the whole group:  the difference between systems designed
primarily for drafting (most IGES-compatible systems), and systems
designed for full 3-D analysis.

<p>
First disclaimer: I really don't know anything detailed about the
internals of the MEDUSA system;  it may or may not have full 3-D
connectivity to connect all the surfaces into consistent solid objects.
However, once the data has been converted to IGES format, the surface
and connectivity data that is necessary to fully describe 3-D solid
objects has been lost.  (That is, unless the not-yet-standard IGES
SOLIDS extensions are used.)

<p>
It is important to note here that the BRL-CAD Package is a 3-D solid modeling
system.  One significant aspect of this is that geometry is restricted to
objects that have both an "inside" and an "outside".  For example, a single
polygon is not a solid, although 5 polygons might be cleverly positioned
to form a solid pyramid, or 6 polygons could be arranged to form a cube.

<p>
The difference is somewhat akin to the difference between the movie lot at
Universal Studios, where largely only the outsides of buildings have been
built, and an actual city, where the complete buildings have been built.

<p>
If you don't need the power of a solid modeling system (for example, if
your only interest is in rendering some externally-generated polygons),
then you may be better off with a different software package.  The
message which I am responding to didn't really indicate the intended
application.

<p>
Having said this, I can offer some practical assistance:

<p>
1)  At BRL, there is an ongoing project to build a converter between the
experimental IGES SOLIDS specification and the BRL-CAD format.  If you
are certain that your modeler can output your model in the IGES SOLIDS
format, then this may be of help to you.  (This project is currently
hampered by not having any serious model in IGES SOLIDS format to test
with, since BRL does not use IGES).  Contact &lt;sue@brl.mil&gt; and &lt;earl@brl.mil&gt;
for more information.

<p>
2)  There is a powerful and easy to use interface for creating BRL-CAD
geometry from within a program;  we call it LIBWDB, the library for
writing databases.  It is this library that we use for all our current
converter programs.  Thus, if you wish to build a new converter (or to
generate procedural geometry), you have only to worry about the input
format (or generation algorithm), and then just call LIBWDB to output
your shapes for later review, editing, and/or analysis.

<p>
A more detailed discussion, if required, should probably move to
the &lt;CAD@BRL.MIL&gt; mailing list.

<p>
	Best,
	 -Mike Muuss
	  BRL-CAD Architect

<p>
----- End of forwarded messages
Date:     Tue, 7 Nov 89 16:22:33 EST
From:     Keith Applin (VLD/VMB) &lt;keith@BRL.MIL&gt;
Subject:  DISUM and TAP for CAD Symposium - draft

<p>

<p>
.nf
The Technical and Programmatic (TAP) Report

<p>
Provided by: Vulnerability Methodology Branch/VLD

<p>
Title: BRL-CAD Symposium '89
.fi

<p>

<p>
The US Army Ballistic Research Laboratory (BRL) sponsored the BRL-CAD
Symposium '89 at the Aberdeen Proving Ground on October 24-25.
This was the second of these annual events and was supported by the American
Defense Preparedness Association.
BRL-CAD is a software package consisting of a 3-D geometric modeling system,
a ray-tracing interrogation library, a generic framebuffer imaging library,
and numerous associated utility packages.
This BRL developed and maintained package has been distributed on a
conditional, non-redistribution basis, free-of-charge to over 500 sites
worldwide.
Such features as source code availability, modularity, adaptability, and
a broad base of applications make BRL-CAD a very attractive package.
This symposium was held to provide an opportunity for an exchange of
information, experiences and ideas associated with the BRL-CAD package.
A total of 23 papers were presented and approximately 100 people attended,
including representatives from academia, DoD agencies, industry, and foreign
governments.
Topics presented covered current applications and work as well as future
planned developments.
BG Malcom O'Neill, commander of LABCOM, presented the keynote address.
The symposium was closed with a panel question and answer session.

<p>
Date:     Wed, 15 Nov 89 3:18:00 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  remrt

<p>
I made a variety of improvements to LIBPKG (replacing pkg_get with
a new pkg_process, plus calls to pkg_suckin).  This addresses some
of the performance buffering complications, which turned out to
be more involved than I had first thought (because of all kinds
of unexpected recursion).

<p>
pkg_get is only used by REMRT and RTSRV;  they have been changed to
also reflect the new usage.  (The ADDCOMPE folks might benefit from
this, too).

<p>
More on this in a few days, after Chris has had a chance to put
it through the wringer.
	Best,
	 -Mike
Date:     Thu, 16 Nov 89 1:31:20 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  fb-rle -F flag

<p>
Thanks for pointing that out.  The string "F:" was missing from the getopt()
arg list;  all the supporting code was present.  I have fixed the source code,
and it seems to perform as expected now.

<p>
	Best,
	 -Mike
From: GEORGE_A_MANEY@cup.portal.com
Newsgroups: comp.graphics
Subject: Re: Information on IGES files wanted...ok
Date: 22 Nov 89 02:12:38 GMT

<p>
IGES is an NBS publication.  I got IGES v3.0 (NBSIR-3359) from

<p>
	US Department Of Commerce
	National Technical Information Service
	Springfield, Virginia 22161

<p>
The cost was about $40.  I believe that version 4 is now available.

<p>

<p>

<p>
				George Maney
				FMC Corporate Tecnology Center
Date:     Fri, 24 Nov 89 16:00:43 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Details on CAD distribution terms

<p>
This letter should answer your questions.

<p>
&gt; What happens if someone of the students doesn't abide by the
&gt; disrtibution terms? I suspect that forwarding our request through the
&gt; embassy creates a law problem: which country's laws apply?

<p>
The way things like this were handled when I was a student was that each
student who would be using the software was asked to sign a short
agreement with the University.  This creates a form of contract between
the student and University which is valid under local law.  Since all we
really ask is that redistribution be handled by us, and that each
commercialization effort be cleared with us, I suspect that such an
agreement would be simple and inoffensive.  If there was an infraction
that came to light, and for whatever reason your University was not able
to deal with it, then our legal and policy offices would have to
consider the details.

<p>
If you require a more detailed response than this, I will have to ask for
an official statement from the legal office, which might take quite some
time.

<p>
&gt;  What about updates?

<p>
Each time we produce a new release, sites that wish to obtain it must
again send us a blank tape.  While we have a modest budget for postage,
we are not funded to provide magnetic tapes.   Until recently, foreign
sites were asked to re-send through the embassy for each update.
Recently our security office has indicated that updates can be handled
directly.  I don't know if we have processed any update tapes in this
new manner yet, but I assume that it will work fine.

<p>
&gt; I fear that the size of the package will make it unacceptably slow in
&gt; 4-MByte workstations. Is this true?

<p>
The package is highly modular;  there are more than 100 different programs.
The 150,000 lines of code figure is for the aggregate.  The two largest
single programs are MGED, the multi-device graphics editor, which has
a base executable of about 1 Mbyte on most machines, and RT, the ray-traced
lighting model, which has a base executable of about 0.6 Mbytes on most
machines.  Of course, dynamic memory is used to contain the data for
the model being constructed.  Without knowing what complexity of modeling
you intend, I can't judge how much memory you might need.  However, I often
run MGED on a Sun-3/50 with 4 Mbytes to perform simple modeling operations
and to inspect existing models, although larger models I work on using a
Silicon Graphics workstation.

<p>
&gt; Since the NTUA acquires continuously many different machines running
&gt; Unix, the equipment list will be necessarily inexact. In the case of
&gt; machines that are installed after the licence agreement is made, can we
&gt; install the package?

<p>
While we don't state it precisely in the letter, all we desire is a list
of machine TYPES (eg, Sun-3, Sun-4, Mac II, etc) that you intend to use
the software on.  This is largely so that if you state that you intend
to use the software on a machine that we don't presently support, we can
either (a) warn you of that, (b) try to persuade you to develop that new
support and share the modification necessary to support that new
machine, or (c) put other users who also have those machines in touch with
you.

<p>
Our distribution tape contains only source code, no compiled binary
code. Therefore, the one tape contains support for all systems. Thus,
you must have a C compiler for each kind of system that you wish to use.

<p>
You are free to use the software on any and all computers that are owned
or operated by your institution.

<p>
Of course, if our software proves helpful in your research, I always
enjoy receiving a copy of any papers that might be produced.  It is a
continuing pleasure to observe the many and varied uses that our
software has been put to.

<p>
	Best,
	 -Mike
Date:     Fri, 8 Dec 89 19:07:53 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  Some Thoughts....

<p>
In my mind there are two parts to the issue:

<p>
1)  Is it honestly the case that TACOM would consider BRL-CAD, or are the
technical issues just the first in a set of "excuses" to justify their doing
what they want to do?

<p>
2)  If it seems that TACOM will seriously consider BRL-CAD, if only certain
technical issues can be addressed, then we need to rapidly produce a written
list of what those issues are.  Within a day or two of having the list,
I should be able to predict roughly how much work it would entail.  Then
we can decide if there is any hope, or not.

<p>
As you hinted at in your message, I suspect that the issue of drawings
will head the list of technical issues.  What I still don't understand
well yet is the role that the drawings are expected to play in the
vehicle development process.  Allow me to elaborate:

<p>
Producing engineering drawings that are ANSI or ISO compliant, suitable
for use on the manufacturing floor, is not difficult, but entails
addressing literally thousands of little details, each of which will
require some special programming.  Thus, setting out to build software
that will product such a drawing would be a large undertaking.

<p>
On the other hand, drawings are entirely unsuitable for computer simulations.
The only audience of a drawing is a human being.

<p>
I believe that it is quite possible to produce a wide variety of drawings,
illustrations, and renderings of 3-D solid models, such that the drawing
would convey the full details of the model to a human being.  However,
these drawings, illustrations, and renderings would NOT be standards-
compliant drawings.  They might or might not contain enough information
to be useful on the manufacturing floor.

<p>
So, the question is, what happens in the prototype design stage?  For
models/drawings, what is the relative emphasis between these three
areas:

<p>
1)  computer simulation
2)  human understanding
3)  specifications for use in manufacturing

<p>
If #3 dominates, then BRL-CAD is not the answer.  If #1 and/or #2 dominates,
then BRL-CAD, perhaps with embellishments, should be a fine solution.

<p>
Can somebody who knows TACOM better than I do please comment?
	Best,
	 -Mike
Date:     Sat, 9 Dec 89 2:22:57 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  ARBN Progress

<p>
I am happy to report that this evening culminated a rather successful
few weeks of code housekeeping.

<p>
I now have a new version of the COMGEOM to BRL-CAD geometry database
converter.  Formerly known as CVT4 and CVT5, this program is now known
as COMGEOM-G, and can handle both versions of the input "deck".

<p>
Furthermore, this new program also properly converts the halfspace (HAF)
and ARBN solids as well.

<p>
Libwdb has been expanded with routines mk_arbn() and mk_ars().

<p>
And, LIBRT now knows how to ray-trace an ARBN.

<p>
MGED can draw an ARBN, but does not yet have any ARBN editing capability.

<p>
So far, for my ARBN test case, I have been using the AH64 Apache heliocopter.
In a few weeks, I will start soliciting for other folks to help test the ARBNs.

<p>
Hopefully, in my spare moments in the next few months, I hope to look at
implementing the few remaining "missing" solids (LOF, WIR, and the ERIM
solids).  Does anyone have a COMGEOM model containing such solids that
they would be willing to share with me for testing purposes?

<p>
In the meantime, *polygons*!

<p>
	Best,
	 -Mike
Date:     Tue, 12 Dec 89 17:05:39 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  BRL Program

<p>
Hi.  I got your phone message.  I'll be away on travel for the rest of the
week, so I'll try to give you some answers here.

<p>
1)  The space subdivision strategy is a non-uniform bin tree.  Space is
divided into a collection of "cells", each of which is a right
rectangular parallelpiped. All intersections are found with the objects
that occupy that cell, before moving on to the next cell.  A bitmap is
kept of which solids have already been intersected, so that solids which
occupy multiple cells are not intersected more than once.  Depending on
the setting of a_onehit, raytracing either stops on the first hit that
passes the boolean equations (gets a TRUE result), or continues until
the end of the ray.

<p>
The existing boolean operation tree (which is separate from the space
partitioning tree) is established in librt/tree.c, largely in the
routine rt_drawobj().  Look for the section with the comment
                /* Store operation on subtree */

<p>
The boolean tree is applied to the segment list in librt/bool.c,
in the routine rt_boolfinal(), using rt_booleval().

<p>
The space partitioning tree is established entirely in librt/cut.c;
the strategy is to establish a single leaf "node" which contains
everything in the entire model first, and then subdivide it until
certain criteria (not the best criteria, I might add) are met.
This subdivision is used in librt/shoot.c to quickly find the
proper leaf node to consider.  This is the only place the space
subdivision tree is used.  Look for this section of code:
                while( cutp-&gt;cut_type == CUT_CUTNODE )  {
                        if( newray.r_pt[cutp-&gt;cn.cn_axis] &gt;=
                            cutp-&gt;cn.cn_point )  {
                                cutp=cutp-&gt;cn.cn_r;
                        }  else  {
                                cutp=cutp-&gt;cn.cn_l;
                        }
                }
                if(cutp==CUTTER_NULL || cutp-&gt;cut_type != CUT_BOXNODE)
                        rt_bomb("leaf not boxnode");

<p>

<p>

<p>
2)  Boolean tree is entered in MGED using "r" (region) command or
the "comb" (combine) command.  Example:

<p>
	r fender.r u tire1 - rod1 - rod2
	comb all u fender.r u hood.r u windshield.r - antenna.r

<p>
u=union, -=subtraction, +=intersection.

<p>
3)  I think you are referring to this block of code?

<p>
int
colorview( ap, PartHeadp )
register struct application *ap;
struct partition *PartHeadp;
{
        register struct partition *pp;
        register struct hit *hitp;
        register struct mfuncs *mfp;
        struct shadework sw;

<p>
        for( pp=PartHeadp-&gt;pt_forw; pp != PartHeadp; pp = pp-&gt;pt_forw )
                if( pp-&gt;pt_outhit-&gt;hit_dist &gt;= 0.0 )  break;
        if( pp == PartHeadp )  {
                rt_log("colorview:  no hit out front?\n");
                return(0);
        }

<p>
The way the routine was set up, with a_hit = &colorview, the routine
colorview() should only be called if the ray hit some geometry.
When the ray is fired from the surface of an object (such as a light
visibility ray or reflection ray), there are occasions where floating
point error will place the exit point of they ray at a slightly
negative distance (typ. -1.0e-10);  in this case, that solid needs
to be ignored.  If no other solid is found, then that is a problem.
Thus the error message.

<p>
Does this help?

<p>
	Best,
	 -Mike
Date:     Mon, 18 Dec 89 9:31:29 EST
From:     Paul Tanenbaum &lt;pjt@BRL.MIL&gt;
Subject:  RTG3 Paper

<p>

<p>
     I have a comment about the method you give on page 10 to obtain azimuth
and elevation from a direction vector.  Does LIBRT normalize the v?  If so,
you can save yourself the call to

<p>
			hypot(v[X], v[Y])

<p>
by computing elevation as

<p>
			elev = asin(v[Z]).

<p>
Certainly MGED uses unit vectors?  I should think that continual updating of
the faceplate in response to knob twists might call for the simpler form.

<p>
     +++paul

<p>
Date:     Mon, 18 Dec 89 15:59:30 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  RTG3 Paper

<p>
Paul -

<p>
There are good reasons for RT applications using atan2() over acos().

<p>
The problem is that asin() is undefined outside the range of -1.0 ..
+1.0, yet sometimes one of the elements of a vector that has "unit"
length may be a few bits larger in magnitude than 1.0 (for example,
1.0000000000001).  On machines like the Cray, the library routine asin()
will abort with a core dump;  in general, the desired behavior is not
well defined.

<p>
By using atan2(), there is no opportunity for floating point error to
cause trouble.  The routine atan2(x,y) takes the length of both the "x"
and "y" sides of the triangle for input.  The routine is well defined
for ALL values of "x" and "y". Small floating point errors in the input
(for example, the hypotenuse having length slightly longer than one)
will result in small changes in the output.

<p>
Thus, atan2() is robust in the face of numeric error, while acos() and asin()
are not.  It is to obtain this robust behavior that LIBRT and applications
built upon it use only atan2().

<p>
I am indebted to Doug Gwyn for first calling this issue to my attention.
	Best,
	 -Mike
Date:     Fri, 29 Dec 89 17:41:13 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  LIBFB_LIBES

<p>
On Spark, I have changed all the Cakefiles so that LIBFB no longer contains
"local vendor" type libraries.  Instead, Cakefile.defs defines a new symbol,
LIBFB_LIBES, that lists any and all loader options that have to be used
when linking against LIBFB.  Thus, all Cakefile rules should look like:

<p>
	LIB_PRE''LIBFB LIBFB_LIBES

<p>
to refer to the framebuffer library.

<p>
This has the benefit of greatly reducing the size of LIBFB, and
permits more flexibility in working around oddities (like BLD on the Crays).

<p>
Please note that this change applies only to the development version so far.
	Best,
	 -Mike
Date:     Sat, 30 Dec 89 5:19:36 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  raytrace.h
BCC:

<p>
Gary -

<p>
This evening, I had to change LIBRT's free partition list from
singly-linked to doubly-linked.  (The active partition list was
always doubly linked).

<p>
I recall your mentioning that you were freeing partition lists
directly in some of your applications.  If you were using the
macros, this probably won't affect you at all.

<p>
Just didn't want you to be surprised.  If something goes awry
due to this change, I'd be interested in hearing about it.

<p>
Stay tuned for more librt work this week.
	Best,
	 -Mike
Date:     Fri, 5 Jan 90 8:14:38 EST
From:     Paul Tanenbaum &lt;pjt@BRL.MIL&gt;
Subject:  [Doug Gwyn: Re: RTG3 Paper]

<p>

<p>
&gt; One of "Gwyn's rules of numerical computation" (unpublished, alas)
&gt; is: "The only inverse trig function you should ever use is atan2()."

<p>
     You once shared a weaker version of this rule with me, namely: "Don't
use atan(), use atan2()."  Your presentation was quite convincing, and I
became a convert.  But I had not heard the stronger form.  A new decade
begins...

<p>
     +++paul

<p>
Date:     Thu, 4 Jan 90 18:34:54 EST
From:     Doug Gwyn (VLD/VMB) &lt;gwyn@BRL.MIL&gt;
Subject:  Re:  RTG3 Paper

<p>
Another advantage of atan2() in many applications is that it gets the
quadrant right.

<p>
One of "Gwyn's rules of numerical computation" (unpublished, alas)
is: "The only inverse trig function you should ever use is atan2()."
Like most rules, there are valid exceptions, but they are quite rare
and one should understand the reasons for the rule before deciding to
violate it.
Date:     Thu, 11 Jan 90 0:23:19 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Interesting LIBRT details

<p>
Greetings -

<p>
Here are the answers to your questions:

<p>
1.  In your space subdivision algorithm, can boxes overlap each other?

<p>
No, at no point in the tree will there be an overlap. The leaves (space
partitioning "box nodes") will never overlap.  A given "cut node" only
""overlaps"" with the children nodes below it.

<p>
    Can solids be in more than one box?

<p>
Yes, absolutely.  Each solid is listed in every box in which it appears.

<p>
    Can a solid in one box overlap a solid
    in another box?

<p>
The relationship between two solids, inside a single box, can be determined
simply by considering the solids listed in that box.  For example, a 1-D
example:
		|------ Box 1 ------|------- Box 2 -----|
  Solid A:           AAAAAAAAAAAAAAAAAAAAAAA
  Solid B:                               BBBBBBBBBBB

<p>
While the ray is in Box 1, there is no overlap between A and B.
Within Box 2, there is an overlap.  What happens in Box 1 will
depend on the boolean formula that defines the region.
(See below for an example).

<p>
    Are the boxes handled in any order (like along the ray)
    or are they handled arbitrarily?

<p>
The boxes are guaranteed to be traversed IN ORDER along the ray, starting
from the ray origin to +infinity.

<p>
  I don't quite understand what the
    following segment of code is doing (it is from the rt_boolfinal() function,
    about 15 lines into the function):

<p>
		/* If partition begins beyond current box, stop */
		if( pp-&gt;pt_inhit-&gt;hit_dist &gt; enddist )
			return;

<p>
In the current version of the code (I did some work on this stuff last
week), the whole block of code now reads like this:

<p>
		/*
		 *  If partition ends before current box starts,
		 *  discard it immediately.
		 *  If all the solids are properly located in the space
		 *  partitioning tree's cells, no intersection calculations
		 *  further forward on the ray should ever produce valid
		 *  segments or partitions earlier in the ray.
		 *
		 *  If partition is behind ray start point, also
		 *  discard it.
		 */
		if( pp-&gt;pt_outhit-&gt;hit_dist &lt; startdist ||
		    pp-&gt;pt_outhit-&gt;hit_dist &lt;= 0.001 /* milimeters */ )  {
			register struct partition *zap_pp;
			if(rt_g.debug&DEBUG_PARTITION)rt_log(
				"discarding early part x%x, out dist=%g\n",
				pp, pp-&gt;pt_outhit-&gt;hit_dist);
			zap_pp = pp;
			pp = pp-&gt;pt_forw;
			DEQUEUE_PT(zap_pp);
			FREE_PT(zap_pp, ap-&gt;a_resource);
			continue;
		}

<p>
		/*
		 *  If partition begins beyond current box end,
		 *  the state of the partition is not fully known yet,
		 *  so stop now.
		 */
		if( pp-&gt;pt_inhit-&gt;hit_dist &gt; enddist )
			return(0);

<p>
		/*
		 *  If partition ends somewhere beyond the end of the current
		 *  box, the condition of the outhit information is not fully
		 *  known yet.
		 */
		if( pp-&gt;pt_outhit-&gt;hit_dist &gt; enddist )  {
			if( ap-&gt;a_onehit &lt;= 0 )
				return(0);
			if( HITS_TODO &gt; 1 )
				return(0);
			/*  In this case, proceed as if pt_outhit was correct,
			 *  even though it probably is not.
			 *  Application asked for this behavior, and it
			 *  saves having to do more ray-tracing.
			 */
		}

<p>
    How do you find only the first hit when a_one_hit is true?  Is this done
    by sorting the boxes in order along the ray?

<p>
The "enddist" stuff only comes into play when a_onehit is on. The idea
is to trace through the minimum number of boxes, stopping as soon as
something is hit. Then the boolean formulas are evaluated, to see if
that produces a true result.  Note that in the case where a_onehit=1,
only the IN hit point is valid;  the OUT hit point may wind up being
incorrectly computed. Consider another 1-D example, with the formula
being "A - B":

<p>
		|----- Box 1 -----|----- Box 2 -----|
Solid A:	     AAAAAAAAAAAAAAAAAAAAAAAAA
Solid B:                            BBBBBBBBBBBBB

<p>
Output partitions:
a_onehit=0	     AAAAAAAAAAAAAAA
a_onehit=1	     AAAAAAAAAAAAAAAAAAAAAAAAA
				    ^^^wrong^^

<p>
In the a_onehit=1 case, ray/solid intersection halts in Box 1, and
the formula A-B is evaluated, giving a TRUE result.  However, the
out point of the partition seems to be at the out point of A,
since solid B has no presence in Box 1.  In reality, the out point
of the partition is coincident with the IN point of B.
However, the definition of a_onehit=1 is that only the FIRST hit
(the IN hit) is valid in the partition returned, so this error in
the OUT hit is acceptable, and saves having to intersect the ray with B.
Since the application set a_onehit=1, it "promised" never to use the
out hit, and so this efficiency measure can be employed.

<p>
The assumption is that a_onehit=1 mode is used primarily for lighting models,
where ordinarily the surface is opaque.  For those rare surfaces where
there is transmission or reflection, another ray needs to be fired anyways,
to take into account bending due to changes in the refractive index
(for the transmission case) or the Snell's law reflection.

<p>
Also note that in the new version of the code, a_onehit is now a COUNT
of the number of accurate hits to be provided by the library in the
result partition.  This has an upwards compatible interpretation with
the previous meaning, and allows certain calculations (pertaining to
internal reflection inside glass, and refractive index tracking) to be
computed much more efficiently, using a_onehit=3 (IN, OUT, IN hits).

<p>
2.  What are the inflip and outflip variables in the partition structure used
    for?

<p>
Let me refer to my 1-D subtraction example again, "A - B":

<p>
		|----- Box 1 -----|----- Box 2 -----|
Solid A:	     AAAAAAAAAAAAAAAAAAAAAAAAA
Solid B:                            BBBBBBBBBBBBB

<p>
result		     AAAAAAAAAAAAAAA

<p>
Understand that the surface normals of each solid always point OUT.
So, you could think of these ray segments having normals like this:

<p>
		|----- Box 1 -----|----- Box 2 -----|
Solid A:	  &lt;--AAAAAAAAAAAAAAAAAAAAAAAAA--&gt;
Solid B:                         &lt;--BBBBBBBBBBBBB--&gt;

<p>
result		  &lt;--AAAAAAAAAAAAAAA--&gt;
				    ^_____ note direction here!

<p>
The normal on the IN hit is just the surface normal of the entry into A.
However, the normal on the OUT hit occurs at the point of entry into B,
and has a normal which is the reverse of B's entry normal.  This is a
natural consequence of subtraction.  Rather than reversing the normal
values in the partition structure, potentially several times, the
pt_inflip and pt_outflip bits are inverted as necessary.  (This saved
some storage in the partition structure, because pt_inhit and pt_outhit
are actually pointers into to the ray segment structure;  the normal
itself is thus shared, and not amenable to modification, without smashing
the interpretation for other partitions).

<p>
As a consequence, application program a_hit() routines all need to have
a scrap of code to take this into account, before using a partition's
normal vector, like this:

<p>
	if( pp-&gt;pt_inflip )  {
		VREVERSE( hitp-&gt;hit_normal, hitp-&gt;hit_normal );
	}

<p>
(Note that the extra {} brackets are needed because VREVERSE is a
multi-line C macro.)

<p>
    Also, is the solhit array in that structure used to indicate which
    solids are intersected by that partition?

<p>
The pt_solhit[] array is a bit vector, indexed by solid number (st_bit).
If a partition is interior to a solid, then that is indicated by
setting the bit, eg, BITSET( pp-&gt;pt_solhit, stp-&gt;st_bit ).
After the partition "weaving" is finished (by rt_boolweave(), called
before rt_boolfinal()), every partition is either entirely inside
a solid, or entirely outside;  all partition/solid crossings have
been resolved by splitting the partition into two at the crossing point.

<p>
3.  I don't quite understand your overlap handler.  Does this refer to a
    partition that lies in two or more regions?  Why would you want to
    eliminate such a partition?

<p>
The definition of a region is that it is a solid object which occupies
physical space.  It is not possible for two solid objects to occupy the
same space;  when this condition is detected in the model, it represents
a modeling error.  The details of the code are somewhat complicated by
the fact that it can automaticly resolve overlaps between an (optional)
explicitly modeled "air" solid and a non-air solid, in favor of the
non-air solid.

<p>
Given than an overlap has been detected, this presents a problem for the
analysis code.  Which region gets to claim the ray (partition)?  The
overlap handler can make two choices:  (a) randomly select one of the
regions, or (b) act as if the partition was not present at all.  Which
one makes more sense depends on the particular application;  the default
overlap handler uses (a).

<p>
	Hope this helps,
	 -Mike
Date:     Tue, 17 Oct 89 15:17:45 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  cakeinclude.sh replaced

<p>
This afternoon, I have replaced "cakeinclude.sh" with the C
program "cakeinclude" that Lee Butler recently wrote.  It is compiled
and installed automaticly by "setup.sh".

<p>
This provides a significant speedup when CAKE builds it's dependency
lists.

<p>
Here are some timings for running on a full directory of source.
The speedup factors are computed from the decrease in elapsed time.
(SWM is Sun-3/50 diskless, SPARK is Gould PN9080, VOYAGE is SGI 4D/240.
The files were accessed via NFS from SPARK).

<p>
Machine	Dir	Script			Program			Speedup

<p>
swm	rt	4.7u 7.0s 1:00 19%	2.1u 2.7s 0:11 43%	5.5X
swm	util	12.2u 22.5s 2:48 20%	5.1u 8.8s 0:24 58%	7.0X

<p>
spark	rt	2.9u 7.2s 0:17 59%	1.2u 2.5s 0:05 65%	3.4X
spark	util	7.8u 23.4s 1:00 51%	3.5u 9.1s 0:21 58%	2.9X

<p>
voyage	rt	1.2u 3.0s 0:05 66%	0.2u 1.0s 0:02 37%	2.5X
voyage	util	3.2u 11.0s 0:20 68%	1.2u 4.0s 0:10 48%	2.0X

<p>
My thanks to Lee for this important development-performance boost!
	Best,
	 -Mike
From: "Phil Dykstra &lt;phil&gt;" &lt;phil@sem.brl.mil&gt;
Newsgroups: comp.graphics
Subject: Re: Raytracer performance on machines?
Date: 26 Sep 89 03:20:19 GMT

<p>
&gt; The whole BRL-CAD package is public domain, ...

<p>
The BRL-CAD package is *not* public domain.  It is Copyright
by the U.S.Army in order to control commercialization of it.
We do distribute the source code at no charge however as long
as the recipient agrees, in writing, to the conditions.

<p>
&gt; but big, crufty, and pretty ancient as ray-tracing packages go.

<p>
Being one of the authors, I had to put in at least two cents worth
of defense.  Big - yes.  Crufty - parts of it.  Pretty ancient -
some of it.  But I wouldn't call things like CSG NURBs, arbitrary
bounding planes, non-uniform space partitioning, parallel *and*
network distributed capability very ancient.

<p>
- Phil
Date:     Sat, 12 Aug 89 7:36:06 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Quaternions added

<p>
I have taken Phil's Quaternion math package, and added many of the
remaining features from Ken Shoemake's May '89 paper (ln, exp, stable
slerp, etc). The macros have been added to h/vmath.h, and the
subroutines now live in librt/qmath.c.

<p>
Perhaps this comming week I'll have a chance to actually USE them
for something, thus testing them.

<p>
	Best,
	 -Mike
Date:     Wed, 23 Aug 89 14:44:25 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  UnixPlot utilities in BRL-CAD

<p>
This note is to address a couple of the questions/problems posted
recently about UnixPlot (plot(5)) utilities.

<p>
pl-X, pl-X10:

<p>
  The reason that these were not included in the standard set of
  compiled software is because they are so minimally useful as they
  now stand.  pl-X has a long way to go before it has any of the
  power of pl-sgi (the SGI IRIS specific plot display program).
  Someday there will be a much better version of pl-X.

<p>
pl-ps:

<p>
  Many UnixPlot files (e.g. ones generated from Tek'ish programs)
  begin with an extra "erase" command.  pl-ps in release 3.7 would
  (incorrectly) output an extra scale command (NEWPG macro) if it
  sees one of these.  I have a much improved pl-ps that fixes this,
  along with output sizing/centering options similar to bw-ps, if
  anyone is desperate to print PostScript plot files.

<p>
Also, note that you can view plot files in MGED with the "overlay"
command.  This provides an alternative way to view them under X
for the time being.

<p>
- Phil
Date:     Sat, 3 Mar 90 3:53:32 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  MGED & lighting model

<p>
I have a very preliminary version of lighting model support in MGED,
to help debug the NMG tessellation routines.  It uses 4 infinite lights
of dubious color and location, but it helps see the facets (eg, on the TGC)
very clearly.  As usual, getting the SGI to do anything useful has turned
out to be a much bigger fight than I had expected.

<p>
A somewhat longer-term project will be to program the lighting model on
the SGI with the same parameters that RT would use when rendering an object.

<p>
I have also started looking at the tessellation of the sphere, using Leech's
algorithm that Paul Stay gave me a copy of.

<p>
	Onwards!
	 -Mike
Date:     Mon, 5 Mar 90 21:03:39 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  comgeom-g

<p>
A new database converter program now exists, called COMGEOM-G.
It replaces the old "Cvt4" and "Cvt5" converters.

<p>
COMGEOM-G will convert a GIFT-style COMGEOM file into a BRL-CAD
binary database suitable for use with MGED, RT, etc.
Automatic units conversion is built-in.

<p>
This new program, and it's manual page, are installed on BRL's Goulds
for initial use.  Please try this program on some of your old COMGEOM
models, and let me know how it goes!

<p>
Note that this converter will convert ARBN solids, but most machines
do not have a copy of MGED et.al. that is recent enough to include the
ARBN support.  However, the latest version of LIBRT raytraces ARBNs
just fine.
	Best,
	 -Mike
Date:     Thu, 22 Mar 90 17:39:05 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  Irksome warning

<p>
Paul,

<p>
If you are using some of our old "pre release" software (e.g. 3.5)
you will see the:

<p>
	rt_shootray:  defaulting a_resource to &rt_uniresource

<p>
message all of the time.  As of release 3.7 however it should only
come out if you have a librt debugging bit set.  So your best bet
is probably to get some up to date software (and ignore the message
until then).  But FYI...

<p>
The resource structure is used to handle parallel processing.  If
you are running on N CPU's, you need N resource structs.  Thus a
single CPU librt process may optionally allocate a resource struct,
while a muti CPU job is required to.

<p>
To use rt_uniresource yourself you unfortunately need to:

<p>
	extern struct resource rt_uniresource;

<p>
	ap.a_resource = &rt_uniresource;
	rt_uniresource.re_magic = RESOURCE_MAGIC;

<p>
At that point it would be best to make your own resource struct.
[The RESOURCE_MAGIC deal is an unfortunate technical detail.]

<p>
- Phil
Date: Fri, 23 Mar 90 08:12:01 PST
From: Vince Skahan &lt;vince@atc.boeing.com&gt;
Message-Id: &lt;9003231612.AA11158@atc.boeing.com&gt;
Subject: ray tracing

<p>

<p>
     When we use rt in mged or pix-fb the ray tracing is done but the
image disappears has soon as it finishes.   This is on and SGI personal
IRIS.  If anyone there knows why this I happens I would be very thankful
for a response.

<p>
  Plese rely to vince@atc.boeing.com

<p>
					Thanks,
						Steve Pirollo
						Boeing Helicopters
Date:     Fri, 23 Mar 90 14:45:30 EST
From:     "Lee A. Butler" &lt;butler@brl.mil&gt;
Subject:  Re:  ray tracing

<p>
The key is to set your environment variable FB_FILE to something like
"/dev/sgil" before you run mged, OR when you run rt, specify the option:
"-F /dev/sgil".  This tells rt that you want a LINGERING framebuffer.  You
will have to close the framebuffer window yourself using the mouse as a
result.  For more information about the options available with your
framebuffer, try the command "fbhelp".

<p>
Lee A. Butler
SLCBR-VL-V					Internet: butler@brl.mil
Ballistic Research Laboratory			   Phone: (301) 278-8740
Aberdeen Proving Grounds, MD 21005-5066

<p>
Date:     Fri, 23 Mar 90 18:49:44 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  ray tracing

<p>
In brief, here is why the window goes away:

<p>
An application (e.g. rt) creates a frame buffer window.  When an
application goes away, so do all of its windows (this is simply part
of the SGI window system, indeed almost all window systems).  The
"l" or linger option causes the application to "fork", i.e. make a
copy of itself to hold the window open, while the parent exits.

<p>
An alternate solution is to have some process *other* than the
application actually own the window, and allow an application to
use that window via this other process.  Code to support this will
be in our next release, where that other process is called "fbserv"
(a "frame buffer server", which is a generalization of the "remote
frame buffer daemon" currently called "rfbd").

<p>
- Phil

<p>
ps: If you use the "l" option I would also suggest the "p" or private
    memory option as well (-F /dev/sgipl).
	(5.61+/IDA-1.2.8) id AA16584; Sun, 25 Mar 90 21:43:57 -0600
	id AA04154; Sun, 25 Mar 90 21:41:13 CST
Date: Sun, 25 Mar 90 21:41:13 CST
From: Luke Lin &lt;lukelin@uxh.cso.uiuc.edu&gt;
Subject: BRL-CAD on a Mac II

<p>

<p>
I was looking through Cakefile.defs when I noticed that it supported
a Mac II running AUX.  I would like to know whether mged runs well
in this environment.

<p>
Also, what hardware is required and/or supported.

<p>
Will a Mac II with an Apple color screen handle the colors of a rendered
image?  Does BRL-CAD support 24 or 32 bit color boards available for the
Mac?  If I add a huge hard disk and a 19 inch color monitor to a Mac II,
can I get something close to the modelling capabilities of an Iris?

<p>
Luke Lin
Electomagnetics Lab
University of Illinois
Urbana
Date:     Mon, 26 Mar 90 13:21:44 EST
From:     "Lee A. Butler" &lt;butler@brl.mil&gt;
Subject:  Re:  BRL-CAD on a Mac II

<p>
The only person I personally know with any experience running BRLCAD on a
Mac II under AUX is on vacation right now, so I can't refer him to you, or you
to him.  My understanding is that it runs under X windows and is
"appropriately slow."  When you realize that the Mac is approximately equal to
a Sun 3/[56]0, you understand the situation.   The Mac, running a 68020 just
doesn't have the horsepower of the Iris running a MIPS R3000 and a hardware
graphics pipeline.  The display on the Mac supports only 8-bit "color-mapped"
mode (to my knowledge) so you begin to see the limitations.  In all, I would
recommend the Iris over the Mac for any serious modelling, unless you have no
budget and already have a (well configured) Mac.

<p>
Lee A. Butler
SLCBR-VL-V					Internet: butler@brl.mil
Ballistic Research Laboratory			   Phone: (301) 278-6674
Aberdeen Proving Grounds, MD 21005-5066
Date:     Mon, 26 Mar 90 13:22:28 EST
From:     "Christopher T. Johnson" &lt;cjohnson@BRL.MIL&gt;
Subject:  Re:  BRL-CAD on a Mac II

<p>
Luke,
I ported BRLCAD 3.x to a MacII running AUX 1.0.  The rt parts and the utilities
worked well.  MGED worked poorly and required a good understanding of BRLCAD
and AUX and MacOS.

<p>
Also under A/UX 1.0 there was no color support and no gray level support. BW only.

<p>
I have sinse ported BRLCAD 3.7 + to A/UX 1.1 running X windows (Apple offering)
Color is not supported in 3.7 for X on A/UX but a slight hack will allow
254 color support.  I expect that 24 bit color support will be availaibe as
soon as we can access a 24 bit card and have A/UX 2.0.

<p>
If you have any questions please feel free to send e-mail and I will
try to help.

<p>
Chris Johnson

<p>
Date: Mon, 26 Mar 90 12:50:03 CST
From: Luke Lin &lt;lukelin@uxh.cso.uiuc.edu&gt;
Subject: Re:  BRL-CAD on a Mac II

<p>
Will the next release of BRL-CAD have better support for the Mac II?  I guess
the bottom line is: will the Mac II version of BRL-CAD be anywhere near the
Iris version in usability?  We have a ton of Mac II's in our lab, but we
do not have A/UX.  We've been thinking about purchasing A/UX along with
a large hard disk so that we can have everything on a Mac, but if it is
not as usable an Iris 4D, then we won't waste out efforts.

<p>
Also, any idea when the next release will be coming out?  I've had problems
compiling 3.7 on a personal iris running IRIX 3.2.1.  I circumvented the
problem by compiling everything on an Iris 4D with an older operating system
and copying the binaries to the Personal Iris.

<p>
Thanks.

<p>
Luke Lin
Electromagnetics Lab
University of Illinois
Date:     Tue, 27 Mar 90 10:05:35 EST
From:     Bill Mermagen Jr. (VLD/VMB)  &lt;wm@BRL.MIL&gt;
Subject:  Re:  BRL-CAD on a Mac II

<p>
Luke,

<p>
	I have been working somewhat with BRL-CAD on the Mac II running AUX.
I recently got a chance to experiment with AUX 2.0, which runs the finder
or MACOS system under Unix. It looks very promising. I plan to port BRL-CAD
3.7 on AUX 2.0 within the next month (as soon as I get a copy). Currently, my
hardware configuration is a Mac cx with 8M, 8 bit color board with Apple rgb
monitor and AUX 1.1.

<p>
	  The higher horsepower Mac fx, with high performance 24 bit
video card, AUX 2.0, ethernet board, and jammed with memory could be a decent
BRL-CAD platform. However, it will not beat a SGI 4D based system.

<p>

<p>
				Bill
Date:     Tue, 27 Mar 90 18:32:47 EST
From:     "Christopher T. Johnson" &lt;cjohnson@BRL.MIL&gt;
Subject:  Re:  BRL-CAD on a Mac II

<p>
Luke,
I expect that future versions of BRLCAD will have better support
for A/UX.  At this time there are a few problems with a BRLCAD on a Mac.
1) Mac II is about 1.05 vgr's (see bench marking comments)
   With the newer versions of MacIIs I believe that this might be
   much improved.  I also hope to have gcc running for the next test
   run.  (gcc failed bencmarks the last time I tried.  Port problem not
   gcc).
2) Most of the current Macs are using 8bit boards.  This gives only 256
   colors.  Under A/UX, X windoes only allows 254 colors (two reserved
   for the cursor.)  When X supports 24 bits, the color support will be
   available. (X for A/UX 2.0).  At this time I am working on dithers
   for color under X and in Color Cut algorthems to get the best color
   possable with only n colors.
3) Mac Color cards are small.  640-480.  The newest cards released by
   Apple support 24bit color in 640-480 but only 8 bits of color in the
   "Two Page Display"  1024-1024 plus.
4) Mged on a small display is painfull.  It is also the case that each
   change of the model (or view point) requires that the display be repaointed
   This can take a LONG time with a large data base.  This should be improved
   after I finish color support as I hope to add some clipping to reduce
   the number of lines drawn.
5) the rt and rrt commands under mged depend on IPC as due a number of
   utilites (pipes).  MacOS programs under A/UX has some interprocess
   communication problems.  (You can end up blocking on a pipe full because
   the MacOS program is not checking input as it is waiting on a child).

<p>
Chris Johnson
Date:     Thu, 26 Apr 90 1:55:03 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  Help needed

<p>
Since the message was

<p>
contributed/toolkit-2.0 Help Extract write error

<p>
that suggests that TAR was unable to write on your local disk.
Check to make sure that you did not run out of disk space.

<p>
You can verify that your tape is completely readable by running

<p>
	tar t

<p>
(perhaps with the "f" option and the device name).  The last file
on the tape is named "zzzEND".  If TAR can read through all the
directory information on the tape as it goes, then you have a good
tape.
	Best,
	-Mike
Date:     Thu, 26 Apr 90 2:23:36 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Tolerance-based drawing

<p>
Over the past two days, I have added support to MGED to permit
the resolution of the display wireframes and NMG tessellated solids
to be variable, controlled by specifying a tolerance.

<p>
In MGED, the command "tol abs 3.5" specifies an absolute tolerance
of 3.5 current units.  This means that objects will be drawn and
tessellated so that no line segment or polygonal facet will be
more than 3.5 units distant from the correct location of the surface,
at the worst case part of the surface.  (Which unit is the current
unit is controlled by the "units" command).

<p>
The command "tol rel 0.01" specifies that a relative tolerance of 0.01
ie, 1%, is to be used.  This means that objects will be drawn and
tessellated so that no line segment or polygonal facet will be
in error by more than 1% of the size of that particular solid.

<p>
The command "tol" will show the current setting.  MGED presently
defaults to no absolute tolerance, and a 1% relative tolerance.

<p>
Either or both relative and absolute tolerances may be specified.
If both are given, the tighter tolerance on a solid by solid basis
will be used.  (The relative tolerance is always relative to the
size of each solid).

<p>
Note that this tolerance only affects the quality of the MGED display;
it has no effect on the geometry that is stored in the database.
Also note that this feature only exists on the development copy of
the software, expect it in "The Next Release".
	Best,
	 -Mike
Date:     Thu, 26 Apr 90 11:01:27 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  Help needed

<p>
On every System V UNIX that has the 14 character filename limit
that I have encountered, the system just silently truncates the
file name to 14 chars.  Has this behavior been "standardized"
away?  If so, I'll change the names on the tape, otherwise,
all that matters is uniqueness in the first 14 characters,
which *is* checked for.
	-Mike
Date:     Wed, 25 Apr 90 3:30:19 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Parallel "prepping"

<p>
This evening I got "parallel prepping" to work, although more properly,
it is "parallel gettree'ing" -- the part marked these days as "PREP" is
for space partitioning, not database prepping.

<p>
Not a full 100% speedup, but by no means shabby!
Here are the raw numbers, there is a summary table at the end.
	Best,
	 -Mike

<p>
------ M35 truck

<p>
Vax reference:

<p>
GETTREE: 65.8user 13.8sys 1:27real 91% 134i+3424d 2335maxrss 3+51pf 3+13940csw

<p>
Voyage, 1 processor:

<p>
GETTREE: 4.86 user + 0.26 sys in 7 elapsed secs (69.4286%)

<p>
Voyage, 4 processors:

<p>
GETTREE: 8.19 user + 1.62 sys in 4 elapsed secs (204.75%)

<p>
------- Mountain Fortress

<p>
Voyage, 1 processor:

<p>
GETTREE: 348.28 user + 34.12 sys in 392 elapsed secs (88.8469%)

<p>
Whiz, 3 processors (should have been 4):

<p>
GETTREE: 437.04 user + 66.49 sys in 182 elapsed secs (240.132%)

<p>
Whiz, finally 4 processors:

<p>
GETTREE: 489.92 user + 87.94 sys in 156 elapsed secs (314.051%)

<p>
Voyage with 4 processors:

<p>
GETTREE: 493.08 user + 89.99 sys in 159 elapsed secs (310.113%)
GETTREE: 491.65 user + 94.27 sys in 161 elapsed secs (305.373%)
GETTREE: 501.71 user + 94.96 sys in 163 elapsed secs (307.798%)

<p>

<p>
# CPU	speedup	Elapsed Time
-----	-------	------------
1	1	392
3	2.15	182
4	2.45	156, 159, 161, 163 (avg=159.75)

<p>
Notes:
1)  Only a portion of rt_gettree() runs in parallel, so 100% speedup should
not be expected.

<p>
2) I/O is involved, giving about 20% system time overhead (red bar in
GR_OSVIEW) pre processor.

<p>
3)  More optimization is possible.
Date:     Fri, 27 Apr 90 3:47:29 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  New Tree Walker

<p>
On and off for the past two weeks, one of my projects has been the
implementation of a new, general purpose "tree walker" for BRL-CAD model
databases. The motivation for writing a new tree walker was to support
the NMG work (Non-Manifold Geometry, more on this in some other note),
which needed a tree walker a little different from the existing ones.
Since yet another tree walker was required, I decided to invest a bit of
extra effort and make the new one a fully general tree walker, capable
of replacing all of the half-dozen existing ones. And, at the same time,
I had a "laundry list" of projects waiting to be done, all of which in
some way affected parts of the tree walker.

<p>
Fortunately, I was able to clean all the laundry :-) .  Here is the list:

<p>
1)  Make this new tree walker be one general routine, suitable for
replacing the existing half-dozen. As a result of this, all the other
features described below should apply uniformly to RT, LGT, etc, as well
as in the viewing commands in MGED ("e", "E", etc).

<p>
2)  Support of non-union operations in combination nodes above
regions.  For example, you can create a group which is "vehicle minus cutout"
for a cutaway view, and you get desired effect.  No longer is it necessary
to remove the cutout from each and every region.  This has been a personal
desire of mine for years.

<p>
3)  Allow using partial (or full) path specifications, accumulating
transformations along the way.  For example, it is now possible to
do
	e vehicle.g/suspension/l-track/idler vehicle.g/engine/drive-train

<p>
and see the "idler" and "drive-train" assemblies drawn in their final
locations, relative to the common combination "vehicle.g".  This satisfies
the suggestion made by Paul Tanenbaum some time ago.

<p>
4)  Allow the model tree to be walked and "prepped" in parallel. For
large models, this can take a significant amount of time;  why not use
multiple processors when they are available?  This feature applies to
MGED viewing commands (like "e", "E", etc), as well as to callers of the
LIBRT routine rt_gettrees().  This suggestion was first put forth by
Doug Gwyn at the last CAD Symposium.

<p>
Note that rt_gettrees() is a new interface, mandated by the need to
(a) aggregate as many tree tops as possible, and (b) provide controls
for the amount of parallelism (ncpus) to actually be employed.
rt_gettrees() replaces rt_gettree() as the preferred way of loading
trees into LIBRT;  of course, rt_gettree() still exists for code
compatibility.

<p>
5)  Better bounding RPP support.  When a region contains non-union
operations between solids, sometimes better model (and region) bounds
could be found than the previous algorithm.  I am grateful to Ed
Davisson for suggesting the improved algorithm which is now used.
Most noticably, this should give much better "view auto-sizing" in RT.

<p>
6)  Uniform support of articulation style animation.  Animation
directives are now handled automaticly by the tree walker, so any
programs that use the new tree walker and desire animation capability
can now easily obtain it.  In particular, this will make it easy
for MGED to preview the articulation scripts that RT has been able to
render for some time now.

<p>
All of these features seem to be working, and MGED has been largely
converted to use the new tree walker.  Parallel tree walking works
and provides a significant speedup on parallel systems, as outlined
below for a (large) sample database (the Mountain Fortress) on an
SGI-4D/240:

<p>
# CPU	speedup	Elapsed Time (sec)
-----	-------	------------
1	1	392
3	2.15	182
4	2.45	156, 159, 161, 163 (avg=159.75)

<p>
Notes on parallel tree walking:

<p>
1)  Only a portion of rt_gettrees() runs in parallel, so 100% speedup can
*not* be expected.

<p>
2) I/O is involved, giving about 20% system time overhead (red bar in
GR_OSVIEW) pre processor.

<p>
3)  Quite a bit more optimization is possible, facilitated by the new
framework.

<p>
SUMMARY

<p>
I believe that the new tree walker addresses all the outstanding issues
in the tree walking area.  It provides new features, improved performance,
and is generally useful, eliminating many different versions of essentially
the same algorithm.

<p>
The new software is now part of the current "development" sources on SPARK.
It will be part of "The Next Release".

<p>
	Best,
	 -Mike
Date:     Fri, 27 Apr 90 4:37:30 EDT
From:     Doug Gwyn (VLD/VMB) &lt;gwyn@BRL.MIL&gt;
Subject:  potential portability problem in librt

<p>
I notice you're using rt_calloc() to obtain a vector of elements of
various types, initialized to "zero".  Unfortunately, bzero() does not
always work for non-integral types.  For example, some Data General C
implementations do not use an all-zeros bit pattern to represent a null
pointer, so when you use rt_calloc() to set up a pointer array it is
not necessarily full of values that compare equal to null pointer
constants.

<p>
There is no simple solution to this (assuming that it is undesirable
to restrict portability to implementations for which this bzero()
trick works).  The obvious two are to just malloc() the array then use
an explicit element initialization loop, or to use memcpy() to blit a
statically initialized object onto the freshly malloc()ed one.  (It is
guaranteed that an object of static storage duration that has no
explicit initializer is preinitizalized to zero values of the
appropriate types, which takes into account architectures that have
unusual null pointer, floating-point zero, etc. representations.)

<p>
I notice also that you're relying on C compiler supporting "flexnames"
(long identifiers).  Since the ANSI C standard guarantees at least 31
characters of significance (except for external linkage), this should
not cause long-term problems, although I bet there are still some C
compilers on commercial systems that don't support flexnames.
Date:     Fri, 27 Apr 90 3:47:29 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  New Tree Walker

<p>
On and off for the past two weeks, one of my projects has been the
implementation of a new, general purpose "tree walker" for BRL-CAD model
databases. The motivation for writing a new tree walker was to support
the NMG work (Non-Manifold Geometry, more on this in some other note),
which needed a tree walker a little different from the existing ones.
Since yet another tree walker was required, I decided to invest a bit of
extra effort and make the new one a fully general tree walker, capable
of replacing all of the half-dozen existing ones. And, at the same time,
I had a "laundry list" of projects waiting to be done, all of which in
some way affected parts of the tree walker.

<p>
Fortunately, I was able to clean all the laundry :-) .  Here is the list:

<p>
1)  Make this new tree walker be one general routine, suitable for
replacing the existing half-dozen. As a result of this, all the other
features described below should apply uniformly to RT, LGT, etc, as well
as in the viewing commands in MGED ("e", "E", etc).

<p>
2)  Support of non-union operations in combination nodes above
regions.  For example, you can create a group which is "vehicle minus cutout"
for a cutaway view, and you get desired effect.  No longer is it necessary
to remove the cutout from each and every region.  This has been a personal
desire of mine for years.

<p>
3)  Allow using partial (or full) path specifications, accumulating
transformations along the way.  For example, it is now possible to
do
	e vehicle.g/suspension/l-track/idler vehicle.g/engine/drive-train

<p>
and see the "idler" and "drive-train" assemblies drawn in their final
locations, relative to the common combination "vehicle.g".  This satisfies
the suggestion made by Paul Tanenbaum some time ago.

<p>
4)  Allow the model tree to be walked and "prepped" in parallel. For
large models, this can take a significant amount of time;  why not use
multiple processors when they are available?  This feature applies to
MGED viewing commands (like "e", "E", etc), as well as to callers of the
LIBRT routine rt_gettrees().  This suggestion was first put forth by
Doug Gwyn at the last CAD Symposium.

<p>
Note that rt_gettrees() is a new interface, mandated by the need to
(a) aggregate as many tree tops as possible, and (b) provide controls
for the amount of parallelism (ncpus) to actually be employed.
rt_gettrees() replaces rt_gettree() as the preferred way of loading
trees into LIBRT;  of course, rt_gettree() still exists for code
compatibility.

<p>
5)  Better bounding RPP support.  When a region contains non-union
operations between solids, sometimes better model (and region) bounds
could be found than the previous algorithm.  I am grateful to Ed
Davisson for suggesting the improved algorithm which is now used.
Most noticably, this should give much better "view auto-sizing" in RT.

<p>
6)  Uniform support of articulation style animation.  Animation
directives are now handled automaticly by the tree walker, so any
programs that use the new tree walker and desire animation capability
can now easily obtain it.  In particular, this will make it easy
for MGED to preview the articulation scripts that RT has been able to
render for some time now.

<p>
All of these features seem to be working, and MGED has been largely
converted to use the new tree walker.  Parallel tree walking works
and provides a significant speedup on parallel systems, as outlined
below for a (large) sample database (the Mountain Fortress) on an
SGI-4D/240:

<p>
# CPU	speedup	Elapsed Time (sec)
-----	-------	------------
1	1	392
3	2.15	182
4	2.45	156, 159, 161, 163 (avg=159.75)

<p>
Notes on parallel tree walking:

<p>
1)  Only a portion of rt_gettrees() runs in parallel, so 100% speedup can
*not* be expected.

<p>
2) I/O is involved, giving about 20% system time overhead (red bar in
GR_OSVIEW) pre processor.

<p>
3)  Quite a bit more optimization is possible, facilitated by the new
framework.

<p>
SUMMARY

<p>
I believe that the new tree walker addresses all the outstanding issues
in the tree walking area.  It provides new features, improved performance,
and is generally useful, eliminating many different versions of essentially
the same algorithm.

<p>
The new software is now part of the current "development" sources on SPARK.
It will be part of "The Next Release".

<p>
	Best,
	 -Mike
Date:     Sat, 28 Apr 90 3:43:42 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  PolySolid Tessellator

<p>
This evening, with a little help from Lee, I wrote the first draft
of the PolySolid "tessellator".  The challenge for this one was not
producing the geometry, but instead, re-derriving the topology of
a set of randomly presented facets.  With the creation of two new
NMG library subroutines, I was able to implement a workable first
version.  Performance is O(n**2) or worse, but at least it works.
I'll see about speeding it up in a few days -- I have some ideas on
how to tackle it.

<p>
The fun part of this is that I was able to convert an 8396 polygon
fractal mountain that Chris had created into an NMG on the first try.
The viewing of it ran in real time on the SGI at about 5fps.

<p>
	Neat stuff!
	 -Mike
Date:     Tue, 1 May 90 3:12:35 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Tolerance on Normals

<p>
A few days ago, I reported that MGED had gained a "tol" command to
specify relative and/or absolute tolerances for use when plotting
and tessellating the primitives. Paul Deitz suggested that for some of
the signature work, it could also be useful to specify *surface normal*
tolerances when facetizing, so that an application program could
specify an upper bound on the angular error in surface normals.

<p>
I have added "normal" tolerances to MGED's "tol" command, and
implemented it in the torus tessellator. The other tessellators will
pick it up next time they are worked on.

<p>
Just for amusement, to satisfy a normal tolerance of 1 degree on the
torus, the tessellator has to generate a 180 * 180 (32,400) polygon
surface! In a large model, this could get to be a lot of polygons.

<p>
	Best,
	 -Mike
Date:     Tue, 1 May 90 1:48:49 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  RT error message

<p>
The message you got:

<p>
                tcg(solidname): only 1 intersect

<p>
usually means that one ray was exactly tangent to the surface of the TGC
when it struck.  If you only got one (or a few) of such messages, then
there is nothing to worry about.  If you got a lot of them, then
I would be interested in seeing a test case that exhibits the problem.

<p>
	Best,
	 -Mike
Date:     Mon, 7 May 90 19:00:54 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  BRLCAD available on Power Series?

<p>
Let me add to Phils remarks.  First, BRL-CAD works fine on the SGI Power
Series.  The machine on my desk is a Power Series 4D/240.

<p>
You may have heard of several current issues between BRL-CAD Release 3.7
and SGI's IRIX Release 3.2 (and 3.2.1 and 3.2.2):

<p>
*)  It is necessary to modify a few files in the BRL-CAD Release 3.7
software before beginning compilation.  These changes are listed on the
erratta sheet that is shipped with every tape.  These changes are
necessitated by the fact that SGI IRIX Release 3.2 was not made
available until after BRL-CAD Release 3.7, so there was no way the
BRL-CAD software could have been tested in advance.

<p>
*)  When running a parallel application that produces images on the
framebuffer, it is necessary to bounce the image through RFBD, because
SGI has a bug in their graphics library that makes it impossible for a
parallel-processing application to produce graphics output (ugh!).
This is easily accomplished by adding the flag -F127.0.0.1: to such
applications, or setting FB_FILE=127.0.0.1: in advance. I knew of this
problem before the BRL-CAD Release was finalized, and spent several days
trying to develop an internal "fix", but nothing worked. When SGI
promised me that this difficulty would be fixed in IRIX Release 3.2,
I gave up.  However, it was *not* fixed in 3.2, so the problem lingers
on. SGI now claims that IRIX Release 3.3 will have this fixed.  Note
again that this is an SGI libgl bug, not a BRL-CAD bug, not that you
as the user care about the distinction.

<p>
Other than these two issues, I believe that BRL-CAD Release 3.7 is a good,
solid release, and should give you no trouble.

<p>
Please pass this information on to your "sources".  If you have any questions,
please feel free to drop me a line.

<p>
	Best,
	 -Mike

<p>
- - - - -

<p>
For those wondering what BRL-CAD is, here is a quick summary.

<p>
The BRL-CAD Package includes a powerful solid modeling capability and
a network-distributed image-processing capability. This software is now
running at over 600 sites. BRL-CAD started in 1979 as a task to provide
an interactive graphics editor for the BRL vehicle-description data
base. Today the package totals more than 150,00 lines of "C" source
code. It runs under UNIX and is supported over more than a dozen product
lines from Sun Workstations to the Cray 2. The package includes:

<p>
	A Solid geometric editor
	The Ray tracing library
	Two Lighting models
	Many image-handling, data-comparison, and other supporting utilities

<p>
In terms of geometrical representation of data, BRL-CAD supports:

<p>
	The original Constructive Solid Geometry (CSG) BRL database.

<p>
	Extensions to include solids made from collections of
	Uniform B-Spline Surfaces as well as
	Non-Uniform Rational B-Spline [NURB] Surfaces.

<p>
	A facetted data representation.

<p>
It supports association of material (and other attribute properties)
with geometry which is critical to subsequent applications codes.
It supports a set of extensible interfaces by means of which geometry
(and attribute data) are passed to applications.

<p>
Applications linked to BRL-CAD:

<p>
o Weights and Moments-of-Inertia
o Optical Image Generation (including specular/diffuse reflection,
	refraction, and multiple light sources, animation, interference)
o Bistatic laser analysis
o A number of Synthetic Aperture Radar Codes (including codes due to ERIM)
o Acoustic model predictions
o High-Energy Laser Damage
o High-Power Microwave Damage
o An array of V/L Codes
o Neutron Transport Code
o Link to PATRAN [TM] and hence to ADINA, EPIC-2, NASTRAN, etc.
	for structural/stress analysis
o X-Ray calculation
Date:     Wed, 9 May 90 20:01:59 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  enmg -&gt; ev

<p>
In the most recent copy of MGED, I have renamed the "enmg" command to
be "ev".  This stands for EValuate.  Few mged users will be likely
to remember what NMGs are, and "enmg" is hard to type.
	-M
Date:     Tue, 15 May 90 22:32:43 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  Bug in MGED

<p>
The big-E command is notorious for having difficulties.  It is often handy
for a "quick look", but does not handle quite a few cases.  The big-E
command operates by approximating everything as an ARBN, and then ray-tracing
the edges to see what is left.

<p>
This does not work for concave objects, like the torus.

<p>
There is also difficulty with the big-E implementation of UNION -- it does
not eliminate common area.  Recall that (A union B) is done by joining
all the parts of (A - B) with all the parts of (B - A).  The big-E command
simply joins all the parts of A with all the parts of B.  Greatly
simplifies the code, but produces displays with extra lines.

<p>
For the future, the big-E command will be entirely replaced with the NMG
support (non-manifold geometry), which is capable of providing the correct
boolean operations on any combination of primitives.  The NMG support isn't
done yet.  Look for it in the next release.

<p>
The big-E command has been a handy visualization tool.  But, please don't
use it's output as a definitive representation of the shape.

<p>
Thanks for the bug report!
	Best,
	 -Mike
Date:     Tue, 15 May 90 18:59:12 EDT
From:     Doug Gwyn (VLD/VMB) &lt;gwyn@BRL.MIL&gt;
Subject:  problem with /usr/brlcad/lib/libplot3.a on WAFFLE

<p>
This library doesn't seem to provide space3(), line3(), color(), etc.
I thought it was supposed to be a superset of /usr/5lib/libplot.a?
Date:     Tue, 15 May 90 23:37:46 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  problem with /usr/brlcad/lib/libplot3.a on WAFFLE

<p>
     This library doesn't seem to provide space3(), line3(), color(), etc.
     I thought it was supposed to be a superset of /usr/5lib/libplot.a?

<p>
No.  From the source code (note numbers 1 & 4):

<p>
 *  These routines generate "UNIX plot" output (with the addition
 *  of 3-D commands).  They behave almost exactly like the regular
 *  libplot routines, except:
 *
 *  (1) These all take a stdio file pointer, and can thus be used to
 *      create multiple plot files simultaneously.
 *  (2) There are 3-D versions of most commands.
 *  (3) There are IEEE floating point versions of the commands.
 *  (4) The names have been changed.

<p>
To support the traditional unix plot commands what you could use is
a simple set of #define's to map xxx(...) into pl_xxx(stdout,...).
[I used to have one of these but a quick search didn't turn it up.]

<p>
- Phil
Date:     Mon, 21 May 90 16:12:53 EDT
From:     Gary S. Moss (VLD/VMB)  &lt;moss@BRL.MIL&gt;
Subject:  Demoing BRLCAD images on a IRIS 4D.

<p>
Hi,
	John Anderson just asked me a question that probably has been
asked many times before: "How do you display your RLE or PIX files in
a loop under the IRIS window manager without the window going away
*and* not end up with a million lingering windows on the screen that
you have to kill manually?".  Well I thought of something that works
real well, I wouldn't be surprised if many of you already discovered
this, but just in case, here goes...

<p>
1) Open a lingering, shared high resolution (1024x1024) window as
follows (the '$' is the shell prompt [;-b yuh-hilk]):

<p>
$ FB_FILE=/dev/sgil fbclear -h.

<p>
2) Send the images with FB_FILE set to the default (/dev/sgi):

<p>
$ FB_FILE=/dev/sgi rle-fb foo.rle

<p>
This will put up foo.rle, then when that window vanishes, the lingering
window underneath it will get an expose event and redisplay foo.rle
because it is a window into shared memory.  This typically happens so
fast that it doesn't look like second the window vanished at all.

<p>
Note: If more than 1 image is to be displayed, substitute step 2)
with a shell loop which prompts you for a Return between images.

<p>
Note: If you are mixing high and low res. images, portions of previous
high res. images will still be visable behind low res. ones.  If
all images are low res, change step 1) to use low res.

<p>
Note also: this works well remotely.

<p>
3) Click the mouse on the window to kill it when you are done.

<p>
NOTICE: If you don't understand this DON'T CALL ME, just send me a
note.

<p>
	-Gary

<p>
Date:     Tue, 22 May 90 14:53:53 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  mged color plot overlays

<p>
I have just revised the development version of MGED so that when the
"overlay" command is used to overlay a UNIX-plot file on top of the
current display, the color information found in the plot file is retained
in the MGED display.

<p>
This has proved helpful for examining some of the NMG debugging.

<p>
	Best,
	 -Mike
From:  Phil Dykstra &lt;phil@BRL.MIL&gt;
Newsgroups: brl.support
Subject: Re:  /usr/include/brlcad vs. /usr/brlcad/include
Date: 23 May 90 19:10:41 GMT
Sender: news@adm.brl.mil

<p>

<p>
    Why don't you check with the BRL-CAD folks instead of guessing.
    They finally were convinced that putting local headers in /usr/include
    was poor practice and have changed BRL-CAD to have them where I said.
    To support (for a transition period) existing applications that were
    looking in /usr/include/brlcad, a symbolic link is appropriate, with
    the expectation that it will be removed eventually.

<p>
Ok, from a BRL-CAD folk:

<p>
No I am not conviced that putting things in /usr/include is a bad
practice.  That is part of a programmers interface to UNIX.  You
should not have to go hunting everywhere for include files and
libraries.

<p>
We have decided to start putting all binaries/libraries/include files
etc. for a package xxx (such as brlcad) under /usr/xxx/* for ease
of system maintenance, and "linking it into the system" via a
symlink in /usr/include/xxx to /usr/xxx/include, and by teaching ld
(where possible) about /usr/xxx/lib, and man about /usr/xxx/man.

<p>
The last release of BRL-CAD was not configured this way.  The next
one will be.  But the symlink will stay.

<p>
- Phil
          29 May 90 17:37 EDT
Date:     Tue, 29 May 90 16:25:59 CDT
From:     Mbowden@redstone-emh2.army.mil
Subject:  Monotonic Non-decreasing Database Sizes

<p>
Apparently, deleting objects within mged does not actually remove data from
the model database. If this is indeed the case, is there a good way to compact
the mged databases?

<p>
					Mark Huston Bowden
					&lt;Mbowden.ssdd@REDSTONE-EMH2.ARMY.MIL&gt;
Date:     Tue, 29 May 90 22:09:32 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  Monotonic Non-decreasing Database Sizes

<p>
You are correct that the on disk database is not compacted when
objects are deleted.  The empty slots will be used however by
any newly created objects.

<p>
If you do wish to compact it one way that comes to mind would be:

<p>
	g2asc &lt; orig.g | asc2g &gt; compacted.g

<p>
- Phil
Date:     Mon, 4 Jun 90 10:35:28 EDT
From:     Paul Tanenbaum &lt;pjt@BRL.MIL&gt;
Subject:  Compiling on victor.brl.mil

<p>

<p>
Tried to compile a fairly simple program on a 4D running BRLCAD 3.2,
and got hollered at about a function I'm not explicitly calling.
According to the man page, USINIT(3P) is a semaphore and lock initializer.
If it's being used within LIBRT, how come the loose end?
     +++paul

<p>
Script started on Fri Jun  1 15:03:33 1990
$ make
	/usr/bin/cc -I/usr/include/brlcad -c opfile.c
	/usr/bin/cc -I/usr/include/brlcad -c sigma.c
	/usr/bin/cc opfile.o sigma.o /usr/brlcad/lib/librt.a -o opfile -lm
/usr/bin/ld:
Undefined:
usinit
*** Error code 1

<p>
Stop.
$ grep usinit *
$ exit

<p>
script done on Fri Jun  1 15:04:23 1990

<p>
Date:     Mon, 4 Jun 90 21:55:03 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  final word: brlcad includes

<p>
I determine the tree structure.

<p>
In this discussion, all parties were "mostly right".  The scoop is:

<p>
Release 3.7 uses /usr/include/brlcad
Release 4.0 (not yet out) will use /usr/brlcad/include, with
a symlink from /usr/include/brlcad.

<p>
The development system operates in the new style (brlcad/include),
but all the production systems operate in the old style (include/brlcad).

<p>
Everything should become consistent with the next release.
I think Doug was just caught off guard by the (admittedly lengthy)
transition period (ie, both arrangements can currently be found).

<p>
	Best,
	 -Mike
Date:     Mon, 4 Jun 90 22:09:39 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  Compiling on victor.brl.mil

<p>
When building an application that uses LIBRT, you must also
link against the library listed as LIBRT_LIBES in Cakefile.defs.
Here is the comment in Cakefile.defs:

<p>
 *                                                              *
 *  Note that when applications link with certain BRL-CAD       *
 *  libraries, they must also link with some related libraries. *
 *  This relationship is listed in this table:                  *
 *                                                              *
 *      LIBRT           LIBRT_LIBES     (formerly RT_LIBES)     *
 *      LIBFB           LIBFB_LIBES                             *
 *                                                              *

<p>
If you are using MAKE rather than CAKE for your application,
then you will need to dig out the particular vendor-specific
settings for these libraries and add them to your Makefile.
In particular, you should note that on the SGI 4D machines:

<p>
#       define  STANDARD_LIBES  -lm -lc
#       define  LIBRT_LIBES     -lmpc
#       define  MGED_LIBES      -lbsd -lgl
#       define  LIBFB_LIBES     LIBPKG -lbsd -lgl

<p>
The settings for these defines will be quite different on other
brands of computer.  Having CAKE automaticly select the right settings
is one of the reasons that we switched from MAKE to CAKE.

<p>
	Best,
	 -Mike

<p>
PS:  Note that for compatability with older Cakefiles, :

<p>
#define RT_LIBES        LIBRT_LIBES     /* compat w/old Cakefiles */
Date: Tue, 10 Jul 90 16:16 PDT
From: LAGUNA@icdc.llnl.gov
Subject: Choosing Workstations for Use with BRL-CAD

<p>

<p>
We are considering the purchase of several workstations for use by
individual engineers.  One of the uses of these workstations will be
modeling with the BRL-CAD package.  Since we want to keep costs low
(under $25K each) and performance good, the workstations which we are
currently considering are

<p>
            Personal Iris
            Sparcstation
            Decstation

We would be interested in hearing any comments about the above machines
as they relate to the BRL-CAD package (or general performance) and any
other machines which the BRL-CAD community deems worthy of examination.

Also, since X is available on all of these machines, we are interested in
whether or not color for X-windows will be available in the next release of
the CAD Package and when that release might be expected.  Thanks.

<p>
                      Gary Laguna
                      Lawrence Livermore National Laboratory
                      laguna@icdc.llnl.gov

<p>

<p>

<p>
Message-Id: &lt;9007101128.AA07850@decpa.pa.dec.com&gt;
Date: Tue, 10 Jul 90 04:29:00 PDT
From: "Mgr. Open System Migration Program, LSE, PDF, SCA  10-Jul-1990 0707" &lt;ellenberger@tle.enet.dec.com&gt;
Subject: Rookie Questions

<p>
I haven't seen any "READ THIS BEFORE POSTING" mail in this group, so
I'll go ahead and ask about some of the things I've run into after
spending an hour or two with the package:

<p>
  1) Has anyone done the Cakefile.defs and other changes necessary
     to install brl on a DECstation rather than a VAX?  If so, I'd
     appreciate mail on the subject.

<p>
  2) What macro packages do I use to format the docs?  -ms does most
     of it, but I'm left with all the tables unformatted and this
     makes install.tr pretty hard to read.

<p>
  3) Has anyone compiled this stuff on a VAX lately?  I tried to build
     it on our 60xx file server running Ultrix 3.1 and I came-up with
     some illegal typedef errors that caused the mged build to abort.
     I haven't tracked them down yet, but it looks like u_char might
     have conflicting definitions between some header file and the
     typedef declarations in dm-xxx.c programs.

<p>
     Also, I scanned the Cakefile and it looks like (although I'm brand
     new to all of this) it doesn't even build the X11 interface.  This
     seemed a little strange since that's pretty standard on Ultrix
     (or even vanilla BSD) these days.

<p>
Sorry if these are too naive, but I'm taking advantage of the "I'm
just a rookie" excuse while I still can...
Date:     Tue, 10 Jul 90 21:54:00 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  Rookie Questions

<p>
    1) Has anyone done the Cakefile.defs and other changes necessary
       to install brl on a DECstation rather than a VAX?

<p>
Sorry.  I don't have any.

<p>
    2) What macro packages do I use to format the docs?  -ms does most
       of it, but I'm left with all the tables unformatted ....

<p>
Use "tbl" first.  Most of the documents will have a comment string at
the top with a sample formatting line.  E.g. from install.tr:
.\" tbl install.tr | troff -t -ms | ...
For the papers, there is a Makefile you can look at.

<p>
    3) Has anyone compiled this stuff on a VAX lately?  I tried to build
       it on our 60xx file server running Ultrix 3.1 ...

<p>
Sorry, "VAX" to me still means a 7xx running BSD.  We have some 60xx's
here running Ultrix.  I will try to make a note to test the next release
on them.  The only Ultrix caveat that I remember is that the C compiler
needed "#define CC_DEFS -Dvoid=int".  That was quite some time ago
though.

<p>
     I scanned the Cakefile and it looks like it doesn't even build the
     X11 interface.  This seemed a little strange since that's pretty
     standard on Ultrix (or even vanilla BSD) these days.

<p>
Since BRL-CAD is not using "Imakefiles" like X, linking to X can be
a very machine type specific, and even site specific thing.  As it
becomes standard on more and more machines, it will probably get
used by default in Cakefile.defs.  For now, look at the couple of
places it is used in Cakefile.defs for an example of how to add it
to your configuration.

<p>
- Phil
Message-Id: &lt;9007191013.AA24250@decpa.pa.dec.com&gt;
Date: Thu, 19 Jul 90 03:13:10 PDT
From: "Mgr. Open System Migration Program, LSE, PDF, SCA  19-Jul-1990 0556" &lt;ellenberger@tle.enet.dec.com&gt;
Subject: More Rookie Questions

<p>
1) I gather from reading one of the documents that there is X support for
   rt, but I can't figure out from reading docs and header files how to
   set FB_FILE or (-F) to drive X.

<p>
2) Since I see the NFF document sitting around, I'm curious whether you
   have any intention of supporting NFF format (i.e. exporting geometry).

<p>
3) If I'm modeling away on X and I want to generate a postscript plot of
   a particular view (and return to modeling), what commands do I issue?

<p>
4) Is there a document that I missed that provides up-to-date information
   such as 1)?  I think I read or at least scanned most of the documents
   and I didn't find the data.
Date:     Thu, 26 Jul 90 4:36:52 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  More Rookie Questions

<p>
&gt; 1) I gather from reading one of the documents that there is X support for
&gt;    rt, but I can't figure out from reading docs and header files how to
&gt;    set FB_FILE or (-F) to drive X.

<p>
See "fbhelp" to find out what frame buffers are supported on your system.
If X is compiled in it will be "/dev/X".

<p>
&gt; 2) Since I see the NFF document sitting around, I'm curious whether you
&gt;    have any intention of supporting NFF format (i.e. exporting geometry).

<p>
I wrote a partial NFF -&gt; g translator a year or two ago.  Exporting
g to NFF would be very hard (missing primitives, no booleans, etc.).

<p>
&gt; 3) If I'm modeling away on X and I want to generate a postscript plot of
&gt;    a particular view (and return to modeling), what commands do I issue?

<p>
You could either (1) "xwd" dump the X window and print it, (2) "release"
the MGED window and "attach" to the "ps" device (which will write a
postscript file for you), or (3) unix plot it with the "plot" command
and convert that to postscript with "pl-ps".

<p>
&gt; 4) Is there a document that I missed that provides up-to-date information
&gt;    such as 1)?

<p>
Libfb(3) has some, and brlcad(1) has some, but "fbhelp" is the best
place to start.

<p>
- Phil
Date: Tue, 10 Jul 90 16:16 PDT
From: LAGUNA@icdc.llnl.gov
Subject: Choosing Workstations for Use with BRL-CAD

<p>

<p>
We are considering the purchase of several workstations for use by
individual engineers.  One of the uses of these workstations will be
modeling with the BRL-CAD package.  Since we want to keep costs low
(under $25K each) and performance good, the workstations which we are
currently considering are

<p>
            Personal Iris
            Sparcstation
            Decstation

We would be interested in hearing any comments about the above machines
as they relate to the BRL-CAD package (or general performance) and any
other machines which the BRL-CAD community deems worthy of examination.

Also, since X is available on all of these machines, we are interested in
whether or not color for X-windows will be available in the next release of
the CAD Package and when that release might be expected.  Thanks.

<p>
                      Gary Laguna
                      Lawrence Livermore National Laboratory
                      laguna@icdc.llnl.gov

<p>

<p>

<p>
Date:     Tue, 10 Jul 90 22:19:07 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  Choosing Workstations for Use with BRL-CAD

<p>
I think it will be a long time (if ever) until an X interface to
BRL-CAD will have as high of performance as a platform specific one
(e.g. GL, SunView, StarBase).  On wire-frame displays (MGED), the
Sparcstation under SunView didn't do as bad as I would have thought
compared to a Personal Iris (PI).  Models would "vectorize" at approx
the same speed.  The PI did the resulting wire frame ~4x faster.
I have not benchmarked the Decstation under X.

<p>
Other non-X factors are that the next release will include support
(in the SGI GL interface) to do hardware lighting of polygonal
surfaces (and some code to generate those surfaces!, but I'm letting
the cat out of the bag).  24-bit color is also worth considering.

<p>
    we are interested in whether or not color for X-windows will be
    available in the next release of the CAD Package and when that
    release might be expected.

<p>
Color X support, yes.  Also "frame buffer servers" which will help
all window system machines.  When?  My unofficial answer is that
I can't see it comming out sooner than September, which may mean
Thanksgiving, but I hope it's before then.

<p>
- Phil
Date:     Thu, 26 Jul 90 21:27:22 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  rt_shootray()

<p>
You can see if the start point lies within the model RPP with
this bit of code:

<p>
(where "rtip" is the return from rt_dirbuild(), and pt[] is the point to test).

<p>
if( (pt[X] &gt;= rtip-&gt;mdl_min[X] && pt[X] &lt;= rtip-&gt;mdl_max[X]) &
    (pt[Y] &gt;= rtip-&gt;mdl_min[Y] && pt[Y] &lt;= rtip-&gt;mdl_max[Y]) &
    (pt[Z] &gt;= rtip-&gt;mdl_min[Z] && pt[Z] &lt;= rtip-&gt;mdl_max[Z]) )  {
	/* The point is inside the model RPP */
}

<p>
	Best,
	 -Mike
Date:     Sat, 25 Aug 90 11:35:20 EDT
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  Various (repost, with additions)

<p>
Greetings!

<p>
Sorry about the long delay in responding, I have been swampped with
my preparations for two big conferences (just back from Scotland,
leave in 2 weeks to teach a tutorial, give a paper, and teach a
class at Ausgraph in Australia).  These trips have overwhelmed me
with work!

<p>
I forwarded your message to Bill Mermagen.  He returned just in time
to dart off to SIGGRAPH.  His E-mail address is &lt;wm @ brl.mil&gt;.

<p>
To answer your questions:

<p>
a) I am unaware of anyone having modified the Cakefiles to create
shared libraries on the Sun.  We now have SunOS 4.0.3, so this is
a good thing to put on the "to do" list.

<p>
b) We have plans to use the GNU command-line editor library for MGED.
We miss this too, using TCSH as our Shell all the time.

<p>
c) Since we write the documentation ourselves (no paid technical writers
here), there isn't as much as I might like.  On the other hand, I think
that we have done astonishingly well.  Terseness is still our biggest
problem, yet more and more users fail to read the manuals due to their
rather large size.  I don't know how to win on this one.  The next set
of manuals will be much thicker;  I don't know if that will help.

<p>
For your specific question, it is true that the LGT man page was omitted
from the manual.  However, there is a full paper on it, so that should
help.  It can also be found on the "Road Map" diagram, which shows that
RT and LGT are the two programs to make color shaded images from a .g
geometry database.  RT is a traditional UNIX-tool, which uses command
line options and/or a command script on stdin to tell it how to
render things.  RT can also be invoked from within MGED, to render
the current view.  LGT is a "user friendly" program to allow a user
without a workstation to change viewpoints, change material properties,
lights, etc.  I prefer to use MGED to do that sort of thing, getting
instant feedback via the wireframe display, but then I wrote RT, so
you might expect that...  Unfortunately, both RT and LGT have one or two
capabilities that the other does not.  Competition keeps things interesting.

<p>
d)  The next version of the manual will almost certainly require three
volumes.  Man pages for all the URT stuff that we install by default
is included in the printed manual, including the libraries.
(At least, that is my impression).  If you go after parts of URT
that came from the "contributed" directory, then you need to print the
extra man pages there, yourself.  (Mostly device specific stuff there).

<p>
The style of the footers was agrivating, but so minor that we didn't
have any interest in re-printing just for that.  Sorry if it bothers
you.  Perhaps you don't understand just how small my group is:
right now, we are three fulltime, with a few occasional helpers
(like Gary Moss, the author of LGT).

<p>
e)  We have quite a variety of database IMPORTERs already.  Not all of
them made it into the 3.7 release.  More is planned in this area.
We have almost no interest in more EXPORTERs, except for PDES.
However, we are just finishing a substantial project to permit
approximate polygonal tessellations of the final "developed" shapes
to be exported.  Useful for hardware rendering, thermal analysis,
radar codes, and the like.  This will be the MAJOR new feature in
Release 4.0, and is also the pacing item for the release date
(currently projected for November, sigh).

<p>
There is also a big push in Trimmed NURBS and a new Graphical User
Interface Management System (G-UIMS), for Release 4.n where n&gt;0.

<p>
	Best,
	 -Mike

<p>
Date:     Mon, 27 Aug 90 11:55:07 EDT
From:     "Christopher T. Johnson" &lt;cjohnson@BRL.MIL&gt;
Subject:  Re:  [Keith Goldfarb: Re: GIFs]

<p>
Hello Keith,

<p>
I'm the person at BRL that is (currently) working with reducing the
amount of information in a picture and still having good resulation.

<p>
The problem of reducing 24 bits of data to 8 bits of bw or 8 bits with
CLUT (gif format) is not at all simple.  Paul Heckbert (sp) wrote the
definitive paper on 24 to 8CLUT.  His method produces some very nice
output.
	1) Cut from 24 to 15bits by chopping the low 3 bits of each color.
	2) With the reduced color space, count the number of hits for
	   each color.  (Generate a histogram)
	3) In color space,
		a) cut at median point along the longest axis of largest box.
		b) repeat until you have 256 boxes.
	4) For each of the 256 boxes, pick the center as a color to put
	   in your CLUT.  (Color Look Up Table)

<p>
Once you have a CLUT the next step would be to translate your original 24
bit image into an 8bit image of CLUT look ups.

<p>
I have not (yet) implimented a color dither program but the theary is the
same as for doing black and white dithering.  I will try and describe
a Floyd-Steinburg color dither.

<p>
	1) zero error line (RGB * length of scanline)
	2) read line from file
	3) going from left to right do:
        Pix += thisline[X];
        thisline[X] = 0;

<p>
        value = closest(Pix);
        diff = Pix - value;

<p>
        if (X+Dir &lt; width && X+Dir &gt;= 0) {
                thisline[X+Dir] += diff*7/16;
                error[X+Dir] += diff*1/16;
        }
        error[X] += diff*5/16;
        if (X-Dir &lt; width && X-Dir &gt;= 0) {
                error[X-Dir] += diff*3/16;
        }
	return(value)
	4) swap thisline and error;
	5) repeat step 3 going from right to left
	6) repeat until end of file.

<p>
The code chunk comes from my black and white version with a few simple
modifications to handle color.  I hope this helps to some extent and
I aplogize for getting long winded.  One of the reasons for babeling
on is that I hope to write a color dither program RSN.

<p>
This is the method that I have been told will generate the best
looking color pictures with a reduced color set.  Things to be
careful of are:
	Finding the closest color.
	Lossing an important color.
	Computing the diffrence between the Pixel read and the Pixel used.
	Adding the Error to the Pixel read.

<p>
The other method that I have used with fair results to view 24bit pictures
with 8 bits or less is to split the 24 bit image into three 8bit images
of the red, green and blue channels.

<p>
Dither each channel as a simple gray scale image down to 6 levels.
Set your CLUT so that CLUT[r*6*6+g*6+b].red=r*255/6;
				       .green=g*255/6;
				       .blue=b*255/6;

<p>
Your final CLUT indexs would be red channel *36 + green channel*6 + blue
channel.

<p>
This uses only 216 colors but should give you a "reasonable" picture.

<p>
Good luck and if you have any questions feel free to e-mail them
to me and or mike.

<p>
Chris Johnson	&lt;cjohnson@brl.mil&gt;
Date:     Thu, 27 Sep 90 10:16:15 EDT
From:     Paul Stay  &lt;stay@brl.mil&gt;
Subject:  re:Spline Solids

<p>

<p>
The teapot program is good example for creating a b-spline solid
using the libspl library, the fact that its from IEEE CG&A, is
just a side light. Other splines solids and surfaces should be created
in a similar manner. But to answer your questions.

<p>
1. What determines the # granules of knots?
2. What determines the # granules of ctls?

<p>
A granule is the size of a database record as defined in
h/db.h and usually is a solid description. In a few instances
such as ARS solids and Spline solids a granule can contain
floating point values of either knots or control points.

<p>
Let say you have a spline surface which has 30 knots.
then the number of granules is

<p>
	gran = (number of floats) + (sizeof( union record)-1) / sizeof(float));
	gran = (gran * sizeof(float)) / sizeof(union record);

<p>

<p>
Thus a spline solid database record consists
	B-spline solid header record
		b-spline surface record
			n granules (records) of floats (knots values)
			n granules (records) of floats (control point values)

<p>
3. What is the difference between geom type 3 and 4.

<p>
	The geom type is whether the b-spline surface control points
	consist of Rational 3 space points (X,Y,Z,W) or
	Non Rational 3 Space points (X,y,Z).

<p>
-Paul


Date:     Tue, 18 Sep 90 9:28:55 EDT
From:     Robert Shnidman (VLD/VMB) &lt;robert@BRL.MIL&gt;
Subject:  Re:  [J. Terrence Klopcic: [J. Terrence Klopcic: Ullyatt]]

<p>
Paul,
	Correct answers ought to be at least as important an issue as
user-friendliness when it come to compare BRL-CAD with FASTGEN.  Let me
related a piece of my limited experience with FASTGEN.  I had John Anderson
run FASTGEN on a PATCH description I obtained from DRI.  As is evident from
the shotline file,  overlaps were not resolved at all!  That is,  volume of
the overlap was assigned to BOTH of the overlapping regions.  If only real
armor were that good.

<p>
				Bob
Date:     Wed, 24 Oct 90 8:16:31 EDT
From:     "John R. Anderson" (VLD/ASB) &lt;jra@BRL.MIL&gt;
Subject:  BRLCAD on a Sparcstation 1+

<p>
	Out of curiosity I installed BRLCAD on my new SParcstation 1+.
I have included the bechmark results below.  Everything compiled fine
with the exceptions of LGT and FBED.  MGED seems to work nicely under
SUNVIEW.  The operating system is SunOS 4.1.

<p>
Abs	whisper.brl.mil	1118.35	561.81	473.52	439.76	509.26	620.54	Tue Oct 23 18:18:24 EDT 1990
*vgr	whisper.brl.mil	8.69	10.31	10.48	10.89	10.38	10.15
Date:     Sat, 3 Nov 90 16:13:48 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Minor additions

<p>
This afternoon, pix-fb, bw-fb, and pixhalve all got a "-a" flag,
which invokes an AUTOSIZE option.  A table of common image sizes
is consulted, and if the input file size matches the size found
in the table, then those values for width & height are used.
This goes a long way to keeping the "headerless" image file formats
convenient to use (given that we often work with images other than
the default 512x512 now).

<p>
I imagine that many of the other programs that deal with images
will also acquire this flag.

<p>
pixhalve is a program to downsample an image to one-half it's original
size.  It does so using a 5x5 filter kernel to obtain each pixel in
the output file.  The intent was that a single-pixel wide feature in
an input image will be guaranteed to influence at least two pixels in
the output file.  This becomes quite significant when producing images
for NTSC video.  When pixhalve takes a 1280x960 image and makes a
640x480 result which is displayed on a composite NTSC monitor,
the results are really terrific looking images.
It may be possible to do better, but this defines a new high point in
our ability to prepare images for NTSC video display.

<p>
Along the way, I added a few lines to libfb/if_disk.c, so that
the framebuffer named "-" is now a synonym for standard output.
If a program that writes to a framebuffer is "well-behaved" and
writes scanlines in ascending order, then that program can be used
in a pipeline for further processing.  As a silly but potent example,

<p>
	fbclear -F- 100 200 100 | pixmatte ....

<p>
is a way of creating a file of a given color of exactly the right size.
(The other, better, way of actually doing this is with GENCOLOR).

<p>
For program that are not well-behaved in writing to the framebuffer,
this can be stacked with the /dev/mem interface, so that things like

<p>
	fbgrid -F "/dev/mem -" | pixmatte ....

<p>
can be done.

<p>
	Best,
	 -Mike
Date:     Thu, 22 Nov 90 3:37:41 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  rtsrv looping on exit: fixed

<p>
This evening I discovered why RTSRV, when aborted, often seems to
leave one CPU spinning:  while trying to send a last message via rt_log(),
it called pkg_suckin(), which noticed that the TCP connection had gone
away, so it went to the user-provided error logger (rt_log, in this case),
which is semaphore protected, and deadlocked in RES_ACQUIRE.
I just changed it to use pkg_errlog() instead (the default),
so that libpkg errors detected by the worker don't result in more
libpkg messages being sent.  (Generally pointless, anyways).

<p>
	Best,
	 -Mike
From: "Michael John Muuss &lt;mike&gt;" &lt;mike@BRL.MIL&gt;
Newsgroups: comp.graphics
Subject: 3/4" -vs- S-VHS, etc.
Date: 22 Nov 90 03:55:05 GMT

<p>
(I wrote this rather lengthy response, to INFO-IRIS.  It seemed worthwhile
to share it with this somewhat larger community as well.  Please note that
many of my assessments are subjective;  if you have achieved different
results, by all means report them.  Mileage varries.  -Mike)

<p>
In a recent note to INFO-IRIS, Stuart Levy wrote:

<p>
&gt;&gt; From what I hear, super-VHS is supplanting 3/4" tape.  (In fact, JVC and
&gt;&gt; Panasonic are discontinuing their 3/4" lines.)  SVHS uses Y/C
component video,
&gt;&gt; with two channels on the (1/2") tape, one each for luminance (Y) and
chroma (C)
&gt;&gt; plus the usual audio stuff.  SVHS is supposedly higher resolution than 3/4"
&gt;&gt; but somewhat worse noise.  The difference is apparently not large, but
&gt;&gt; SVHS equipment is decidedly cheaper.  ...

<p>
This is somewhat misleading.  3/4" U-matic tape is also recorded
as separate luminance (Y) and chroma (C), as is regular VHS, Super-VHS,
and many other formats.  The differences between these formats are
in terms of bandwidth available for each signal, and signal/noise ratio.

<p>
While some very low-budget operations have begun mastering on S-VHS,
there is no question that S-VHS is a lower quality format than 3/4".
A 5th or 6th generation dub on 3/4" is still of acceptable quality
(although not prizewinning), while the same can not be said of even
a 3rd generation S-VHS dub.  Certainly not with any S-VHS equipment that
I have worked with.

<p>
It is important to note that the Y/C bandwidths on 3/4" come in two
flavors as well.  Regular 3/4" has about 260 lines of resolution
(e.g. about 520 pixels/scanline), while SP-format 3/4" has about
360 lines, or about 720 pixels/scanline.  The NTSC format is
bandwidth limited by law to have no more than 720 pixels/scanline,
so this is as good as it gets in real NTSC.  Wider bandwidth signals
can be easily created in your studio (the "multiburst" signal from
most test sets is an example), but it isn't real NTSC.
Thus, the SP version of 3/4" fills roughly the same need for 3/4"
users that S-VHS serves for VHS users, but with the 50 dB video S/N
and tape speed stability of the 3/4" format.

<p>
A QUALITY COMPARISON:  Subjective, and Measured.

<p>
Just last week, I had the opportunity to make several dubs of my recent
video, and used this chance to compare S-VHS to regular (not SP) 3/4".
I tried to give the S-VHS dub every advantage. I used my NEC 1000 S-VHS
machine ($1000), which I have measured as having about 375 lines of
resolution in S-VHS mode (i.e., full NTSC bandwidth) on the composite
NTSC input. Note that the manufacturer claims this machine to have "425
lines of resolution" when fed a non-band-limited S-Video (Y/C) input
signal (which is hard to come by).

<p>
I connected the output of the 1" mastering machine directly to the
composite NTSC input of my S-VHS deck, and used TDK's best S-VHS tape.
Hi-Fi sound was also taken straight from the 1" machine. (BTW, 1"
machines have rather mediocre sound, ~45 dB S/N, compared to better than
80 dB S/N on a Hi-Fi VHS or S-VHS deck). Next, I also made a copy on
3/4", through the regular distribution amps, i.e. I had additional gunky
circuitry in the signal path over the S-VHS dub.

<p>
Comparing my S-VHS dub to the 3/4" dub requires no special talent.  The
S-VHS copy is *much* noisier than the 3/4" copy.  And recall, this
is conventional 3/4", *not* the wider bandwidth SP format. The S-VHS is
still quite good to look at, but not nearly as nice as the 3/4". If you
are accustomed to viewing NTSC only on VHS tape, you would not be upset,
but if you are accustomed to viewing NTSC as it exists in the mastering
process, you would mourn the loss.

<p>
However, it is true that 3/4" is no longer the best way to capture video.
In order of increasing quality, the competition comes from Hi-8,
Betacam SP, D-2 digital, and D-1 digital.  Betacam SP is a "component"
video system, recording Y, R-Y, and B-Y signals, rather than Y and C.
D-2 is a "composite" (Y/C) digital format, and D-1 is the "component"
(Y, R-Y, B-Y) digital format.  D-2 decks are now available for less than
$50k, and the prices are comming down.  Since a good 3/4" machine costs
from $10k to $30k, this isn't such a large price difference (reference:
the Sony BVU-850 and BVU-870).  Note, however, that while the digital
formats offer zero generation loss, the digital format has inherrent
quantization, which can be quite noticable in the D-2 format.
8 bit samples are just not wide enough;  we need 10 or 12 bits
to satisfy the discerning eye, even with dither used to prepare
the original signal.

<p>
Mind you, I'm no big fan of NTSC -- it is a very limiting, low quality
video format.  But, it has supplanted 16mm film (a superior quality
format) as the standard way of communicating scientific results,
so one might as well understand it, and master it.  NTSC, when done
well, can be a very striking and effective way of communicating.

<p>
AN EXAMPLE OF MAKING A VIDEO

<p>
Just to give you a quick idea of how I created my recent video:

<p>
Images were created in RGB at 1280x960, and decimated using a 5x5 filter
kernel down to 640x480.  These RGB images were converted to Y/U/V format,
the U and V data was low-pass filtered to meet NTSC bandwidth limitations,
and the YUV data was transmitted over Ethernet to an Abekas A60 digital
video disk ($60k), where they were stored in D-1 digital video format.

<p>
When an entire segment of video had been loaded onto the Abekas, it
was played back in real time, under control of an FCC-approved broadcast
quality sync generator.  The RGB outputs of the Abekas were sent to a
Faroudja CTE-1 RGB-&gt;NTSC encoder ($7k), and the composite NTSC was
recorded on a Sony BVU-870 3/4" VTR ($30k) with SMPTE time code generator.

<p>
Real-time sequences were captured from an SGI-4D/240 GTX ($100k) with
CG3 board ($7k?). The sync pulses were fed into the CG3.  With the SGI
in NTSC mode, genlocked to "house sync", it provided RS-170 RGB, which
was fed into the Faroudja encoder, and the composite NTSC was recorded
on the BVU-870. I note in passing that the CG3 still does not succeed in
producing broadcast quality video, although it is far better than
earlier attempts.  Unlike earlier SGI CG boards, the output of the CG3
is sufficiently good that it can actually be used, if you don't mind
"tweeking" the Faroudja into forgiving SGI's sins.

<p>
Each segment went onto a separate 3/4" cartridge, and all were indexed
event-by-event according to the time codes.  This allowed the script to
call for segments to be assembled with individual frame accuracy.
(Allow me to make a BIG PLUG for the use of SMPTE time code on your
video tapes.  It makes the editing process vastly easier, and more
accurate).

<p>
All the 3/4" original tapes went into a big box, and I took it all to
our 1" edit suite.  The original tapes were read on a pair of Sony 3/4"
machines (VO series), stablized by a time base corrector (TBC), routed
through an edit controller with Ampex effects box (for fades and wipes)
and Ampex ADO (for inset screens, flip-away effects, and "MTV" style
rotating and tumbling images), after which each finished sequence was
recorded on an Ampex 1" machine ($50k).

<p>
After the video was complete, I added the music to Channel 1, going from
Compact Disc to the 1" machine via a sound board, where the mix to mono
was accomplished. Then, I recorded the narration in a sound booth, onto
a 3/4" tape. Using the same edit system, the narration track was copied
onto the 1" machine (although I'm proud to say that in 8.5 minutes of
narration, I only made one "flub" that we had to splice in a replacement
for.  This was done using the edit system, just like editing video).  At
this point, the master tape was finished.

<p>
Dubs for the final distribution were made from the 1" master onto 3/4"
and VHS, through a 1-&gt;12 video and audio distribution amplifiers. Thus,
the distribution copies delivered to the clients are only 3rd
generation. Since the trip from 3/4" to 1" is "nearly lossless", the
distribution copies have excellent quality. Given that, in my instance,
distribution is done on 3/4" and VHS, increasing the quality of the
intermediate steps is not likely to make a noticable improvement in the
quality of the product.  The 1" master would be completely suitable for
broadcast.

<p>
Even if you don't have the financial resources to engage the services of
a 1" edit suite for your video productions (not that it is very
expensive), and you do all your production and editing in 3/4", you will
get a high quality result.  Certainly better than anything you could produce
on Super-VHS.

<p>
FRAME AT A TIME

<p>
In the past, I have also done quite a bit of frame-at-a-time recording
of video, using the Sony 3/4" machines and a Lyon-Lamb VAS-4 VTR controller.
This produces results of equal quality (all other elements being equal),
but takes longer.  It is also more of a bother to find and fix botched
frames when recording this way.  It also requires a much smaller
investment in equipment!  ($5k for Lyon-Lamb Mini-VAS, plus a VTR).

<p>
LASER DISCS

<p>
On a related topic that I won't bore you with this evening, I recently
investigated the quality of LaserDisc players.  They are much better
than consumer videotape (even Beta), but 3/4" tape does even better.
The machines evaluated were the Pioneer CLD-91 ($2000) and Pioneer
CLS-S2 ($3500) [the worlds finest Laser Disc player at the moment].

<p>
SUMMARY

<p>
*)  3/4" videotape is no longer the best thing around.
*)  3/4" can be used to produce excellent results.
*)  3/4" beats S-VHS every time (video, not audio).
*)  3/4" is mature, and not too expensive.

<p>
Many alternatives exist, and lots of good stuff is happening.  Keep your
eyes on Betacam SP and D-2.  If you have (or are) a good video engineer,
there are lots of alternatives.  If you don't have access to a good
video engineer, the business of video recording still has a lot of
pitfalls, and it will pay to be very conservative.  Be suspicious.

<p>
Also, most large universities and companies have a TV studio, and there
are many commercial firms in the business.  Strongly consider using them
to assist with your post-production needs.  The aid of a professional
video editor (person) can greatly increase the quality of your result;
knowing when and how to use fades, wipes, etc, is more of an art than a
science. Rates are generally in the $100/hour to $200/hour range, and
often less.

<p>
	Best,
	 -Mike Muuss

<p>
PS:  In case you are interested, all the image generation software,
image filtering software, Lyon-Lamb controller software, etc are all
included as a small, but significant, part of the BRL-CAD Package,
which we make available for free.  See SGI's software partners catalog
for details, or send E-mail.
From: Dave Martindale &lt;dave@imax.com&gt;
Newsgroups: comp.graphics
Subject: Re: 3/4" -vs- S-VHS, etc.
Keywords: NTSC, video, videotape, recording
Date: 23 Nov 90 05:20:59 GMT

<p>
In article &lt;14556@smoke.brl.mil&gt; mike@brl.mil writes:

<p>
[ lots of useful and interesting stuff about video recording.  However,
there were a few errors I'd like to correct.]

<p>
&gt;Regular 3/4" has about 260 lines of resolution
&gt;(e.g. about 520 pixels/scanline), while SP-format 3/4" has about
&gt;360 lines, or about 720 pixels/scanline.

<p>
Video resolution is given in lines, not line pairs.  2 lines == 1 line pair
== 2 pixels.  So a vertical resolution of 485 lines is really just
485 pixels.  Horizontal resolution is a bit odd, since it is usually
specified as "lines per picture height" rather than "lines per picture
width".  Because of the 4:3 aspect ratio, a horizontal resolution figure
of "330 lines per picture height" is really "440 lines per picture width",
or 440 pixels, or 220 line pairs.

<p>
Even when you see resolution quoted as "330 lines" with no other qualifiers,
they really mean 440 pixels H resolution.  This is because vertical resolution
should always be the same with a properly-interlaced TV, so nobody
quotes it, while horizontal resolution depends on bandwidth which does vary.
And because H resolution is quoted in terms of picture height, not picture
width, even when only H resolution is being given.

<p>
This is all a bit weird for those of us used to thinking in pixels.

<p>
&gt;The NTSC format is
&gt;bandwidth limited by law to have no more than 720 pixels/scanline,
&gt;so this is as good as it gets in real NTSC.

<p>
An NTSC signal is limited to 4.2 MHz bandwidth when broadcast.  This is
equivalent to just about "330 lines" or 440 pixels (horizontal).
More pixels than that doesn't gain you any resolution if it's going to
be broadcast.  Some frame buffers have 512 because it's a convenient
number (power of 2), some use 640-650 because it's a convenient number
(square pixels), but they won't give any more resolution when broadcast.

<p>
720 pixels is what is used by D-1 digital recorders; that's just what
the width comes out to with a 13.5 MHz sampling rate.  This probably
allows them to have about a 6 MHz bandwidth, but anything beyond 4.2 will
be lost on broadcast (but is useful for multi-generation processing).

<p>
All of the above figures are for luminance bandwidth only.  Colour
bandwidth is always less.  D-1 digital recorders give half as much
bandwidth for the two colour components as the luminance gets,
and everything else is worse.  The NTSC standard itself specifies
about 500 kHz bandwidth for the Q colour channel, which is equivalent
to about 53 pixels horizontally.  Yes, yechh.  That's why colours
smear well beyond the boundaries of the pixels that are supposed to
be coloured.  The I channel gets somewhat more than twice that, but
most (or all) consumer TV sets discard it, limiting both I and Q
to 500 kHz.

<p>
	Dave Martindale
Date:     Mon, 26 Nov 90 13:26:49 EST
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
Subject:  Re:  lgt on Sun3

<p>
Mike,
	I fixed the warnings generated on vision (under SunOS 4 Sun fixed
the signal() declaration).  Since there is no preprocessor define specific
to SunOS 4, warnings will now occur under older releases unless the user
compiles with -DSunOS4=0.  Correct code will be produced either way, but
perhaps we should document this somewhere, besides in the source code.

<p>
	There is a good chance that similar warnings will appear on other
machine types; It's hard to predict when various vendors will fix this.

<p>
Thanks for the bug report,
-Gary

<p>
Date:     Thu, 29 Nov 90 21:48:44 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  a troff link with CAD?

<p>
I use a package called "psfig" under Latex (or TeX) for including
postscript figures in reports.  BW and PIX files, as well as MGED
displays, can be converted to postscript and included that way.
If you are running under X, the program xdvi can be used to preview
the TeX output (with blank spaces where the figures go) or "gs", the
GNU postscript interpreter, can show you the final postscript output
(from dvips) figures and all, although this is pretty slow.

<p>
There is a TROFF version of psfig, though I have not tried it.  I
believe that Mike Muuss &lt;mike&gt; and Lee Butler &lt;butler&gt; have used it
before so you may want to ask them for details.

<p>
- Phil
Date:     Fri, 30 Nov 90 0:57:15 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  sun 386i

<p>
While none of us at BRL has tried it, I know a couple of people
that seem to have compiled BRL-CAD successfully on PC/AT's running
Interactive Systems Unix.  It apparently only takes a few minor
changes.  I can send you the changes I got thanks to Garry Paxinos.
[In fact I just added them to our own sources since you reminded
me about it.]

<p>
- Phil
Date:     Wed, 5 Dec 90 5:51:46 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  new g2asc, asc2g

<p>
This evening, I spent several hours testing new versions of g2asc and
asc2g that were provided by Sue.  These new versions have two
major areas of enhancement:

<p>
1)  They support particle and pipe solids (similar to GIFT WIR solids).
    (Some of the code was temporarily grafted out of LIBRT until the
    import/export interface exists).

<p>
2)  The new asc2g uses LIBWDB for most of it's output operations,
    making it easier to understand and maintain.  This is also an
    important precursor to the (post-Release-4.0) database format change.

<p>
This is a nice piece of work.

<p>
Because these converters are central to database integrity, and are
critical in the moving of databases from one architecture to another,
they got rather extensive testing.  I solicit other BRL-CAD developers
to experiment with them for a few minutes, when convenient, as an extra
double-check of my testing.

<p>
The new software correctly converts all the databases in wolf:/m/cad/db
back and forth, with these caveats:

<p>
1)  LIBWDB has the axis of the torus rotated 45 degrees from the way
    that ASC2G did it.  This results in the same torus, but
    the numbers in the file are different.  This kicks out a handful
    of non-harmful differences when comparing solid type 16 records (TOR).

<p>
2)  Unused entries for the sphere, polygon, etc, are zeroed now;  they
    used to have garbage in them, which was carried around in the .asc file.

<p>
3)  The c_num and m_num fields are forced to zero, and do not propagate.
    (These were GIFT solid numbers once upon a time, and are no longer
    relevant.)

<p>
4)  The current working units from the last MGED session (kept in the ID
    record) are not brought along, because the mk_id() routine does not
    allow this field to be set.

<p>
With these caveats, the new converters produce the "same" results as
the old converters.  Please speak up if you can break them.

<p>
	Best,
	 -Mike
Date:     Mon, 25 Jun 90 13:42:56 EDT
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
Subject:  MGED not giving some READ-ONLY messages?

<p>

<p>
Someone just got confused when edcodes failed to update the
desired region characteristics; it turns out that the file
was read-only and that MGED did NOT complain about it being
read-only!
Other things I found that weren't quite right: units command
gave no complaint, title command gave only "error", and notice
what happened in my attempted use of "killall r1" in this script
on vmb.brl.mil host:

<p>
Script started on Mon Jun 25 13:40:53 1990
[env]$ mged test.g
BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 88
    Fri May 19 23:12:38 EDT 1989
    mike@spark.brl.mil:/m/cad/.mged.sel

<p>
test.g:  READ ONLY
attach (nu|tek|tek4109|ps|plot|X)[nu]?
ATTACHING nu (Null Display)
Untitled MGED Database (units=mm)
mged&gt; tops
r1/R
mged&gt; killall r1
mged&gt; tops
a                   b
mged&gt; q
$ mged test.g
BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 88
    Fri May 19 23:12:38 EDT 1989
    mike@spark.brl.mil:/m/cad/.mged.sel

<p>
test.g:  READ ONLY
attach (nu|tek|tek4109|ps|plot|X)[nu]?
ATTACHING nu (Null Display)
Untitled MGED Database (units=mm)
mged&gt; tops
r1/R
mged&gt;
Date:     Fri, 7 Dec 90 23:17:07 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  MGED not giving some READ-ONLY messages?

<p>
Carl -

<p>
This week I have been working on patching up bugs and deficiencies in
MGED and related geometry database tools.  In reference to the note you
sent this summer (see below) I can report the following progress:

<p>
*)  The MGED command EDCODES has been fixed to give error messages on
read-only databases. The problem was that EDCODES didn't use the library
routine db_put(), but instead had a (void)write() call.

<p>
*)  The UNITS command was not checking an error return.  It now prints
a warning message if appropriate.

<p>
*) The TITLE command message "error" has been made more descriptive.

<p>
*)  The KILL and KILLALL commands have been changed to check error returns,
and make appropriate remarks.  In general, all uses of the db_*() I/O
routines have had their error return codes checked.  Here is a sampling
of the error messages that might result:

<p>
/* For errors from db_get() or db_getmrec() */

<p>
Database read error, aborting

<p>
/* For errors from db_put() */

<p>
Database write error, aborting.
The in-memory table of contents may not match the status of the on-disk
database.  The on-disk database should still be intact.  For safety,
you should exit MGED now, and resolve the I/O problem, before continuing.

<p>
/* For errors from db_diradd() or db_alloc() */

<p>
An error has occured while adding a new object to the database.
The in-memory table of contents may not match the status of the on-disk
database.  The on-disk database should still be intact.  For safety,
you should exit MGED now, and resolve the I/O problem, before continuing.

<p>

<p>
/* For errors from db_delete() or db_dirdelete() */

<p>
An error has occured while deleting '%s' from the database.\n", _name); \
The in-memory table of contents may not match the status of the on-disk
database.  The on-disk database should still be intact.  For safety,
you should exit MGED now, and resolve the I/O problem, before continuing.

<p>
Overall, this should make MGED more informative about errors.
Hopefully, the only common error encountered will be users trying
to modify READ-ONLY databases.  :-)

<p>
(Of course, these modifications are only in the experimental versions of
the software.  At BRL, the latest versions should be available for
internal testing in a few weeks.  Just in time for Christmas!)

<p>
	Best,
	 -Mike

<p>
------------------------------------------------------------
Date:     Mon, 25 Jun 90 13:42:56 EDT
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
Subject:  MGED not giving some READ-ONLY messages?

<p>

<p>
Someone just got confused when edcodes failed to update the
desired region characteristics; it turns out that the file
was read-only and that MGED did NOT complain about it being
read-only!

<p>
Other things I found that weren't quite right: units command
gave no complaint, title command gave only "error", and notice
what happened in my attempted use of "killall r1" in this script
on vmb.brl.mil host:

<p>
Script started on Mon Jun 25 13:40:53 1990
[env]$ mged test.g
BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 88
    Fri May 19 23:12:38 EDT 1989
    mike@spark.brl.mil:/m/cad/.mged.sel

<p>
test.g:  READ ONLY
attach (nu|tek|tek4109|ps|plot|X)[nu]?
ATTACHING nu (Null Display)
Untitled MGED Database (units=mm)
mged&gt; tops
r1/R
mged&gt; killall r1
mged&gt; tops
a                   b
mged&gt; q
$ mged test.g
BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 88
    Fri May 19 23:12:38 EDT 1989
    mike@spark.brl.mil:/m/cad/.mged.sel

<p>
test.g:  READ ONLY
attach (nu|tek|tek4109|ps|plot|X)[nu]?
ATTACHING nu (Null Display)
Untitled MGED Database (units=mm)
mged&gt; tops
r1/R
mged&gt;
Date:     Fri, 7 Dec 90 23:23:45 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  [Carl Moore:  error message in mged]
          [Daniel C. Dender:  Re: error message in mged]

<p>
This message addresses the issues raised by Carl and Dan, below.

<p>
A new version of db_addrec() exists, which will try hard to create
temporary names for duplicates.  As an example:

<p>
foo.g:  READ ONLY
attach (nu|tek|tek4109|ps|plot|sgi)[nu]?
ATTACHING nu (Null Display)
db_diradd: Duplicate of 'tor', given temporary name 'A_tor'
db_diradd: Duplicate of 'platform.s', given temporary name 'A_platform.s'

<p>
Thus, the second instance of the duplicated object can be referred to
by it's temporary name, and perhaps given a better name.  E.g.:

<p>
mv A_tor torus3

<p>
	Best,
	 -Mike

<p>
----- Forwarded message # 1:

<p>
Date:     Thu, 1 Nov 90 12:11:55 EST
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
Subject:  error message in mged

<p>
I made 2 ".g" files via the converting of old ".vg" files.  Now I am getting
messages like this which do not go away even if I keep group "hepro" in a
separate file, kill "hepro", and then concat it back in.  What is the meaning
of this message?

<p>
db_diradd( x10039ef0, hepro, addr=x8480, len=5, flags=x2) duplicates entry x1008a300 d_addr=x7e00

<p>
----- Forwarded message # 2:

<p>
Date:     Fri, 2 Nov 90 23:32:38 EST
From:     "Daniel C. Dender" (SE|andr) &lt;dender@BRL.MIL&gt;
Subject:  Re:  error message in mged

<p>

<p>
&gt; What is the meaning
&gt;of this message?
&gt;db_diradd( x10039ef0, hepro, addr=x8480, len=5, flags=x2) duplicates entry x1008a300 d_addr=x7e00

<p>
Carl,

<p>
This message is a diagnostic printed at the beginning of an mged session
when mged is building up an internal directory of all the object names
defined in the database. It means that the name mentioned has already been
defined once in the database, and that this second definition for the name
is being ignored as if it did not exist *during this mged session*.

<p>
Try this procedure to see what you actually have.
1) Run the conversion from .vg to .g again (might as well start with a clean
   slate).
2) Keep the group "hepro" into a separate file, and kill it in this database.
3) Exit mged, and then start it up again. This allows mged to build its
   directory anew and thus pick up the directory entry it ignored previously.
4) You should see a group called "hepro" still in your database. If so, then
   somehow there were two objects in the old .vg database called "hepro".
   I don't really know how that would have happened, but there was a lot
   less error checking back then.
5) Assuming you find that you still have an object "hepro", compare it
   to the one in the separate file. (You can bring the other file into
   the database with some prefix just for comparison.)
6) If, by chance, you still receive the same error message, then you will
   have to repeat this procedure until everthing in your database is
   singly defined.

<p>
One duplicate entry message is printed for each object name found
duplicated. If you see the same object name appearing multiple times
then you have some serious work cut out for you.

<p>
You get rid of the extra definitions by 'keep'ing the duplicated object
into a separate file. Then you kill the object in your database, and exit
mged. Now start mged up again, kill the object again (to get rid of the
entry that was being ignored), and 'concat' the object back in from your
separate file.

<p>
Good luck.

<p>
Dan Dender

<p>

<p>
----- End of forwarded messages
Date:     Fri, 7 Dec 90 13:41:32 EST
From:     Natalie Eberius &lt;barker@BRL.MIL&gt;
Subject:  Multiple Processors

<p>
I have written an application that uses raytracing and I
am interested in utilizing multiple processors.  What do
I need to do to implement something similar to the -P
option on rt?

<p>
		Thanks,
		Natalie Eberius &lt;barker@brl&gt;
		6980
Date:     Thu, 13 Dec 90 6:13:32 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
Subject:  Changes to MGED for blit

<p>
This morning I've made some modifications to mged's tek4014 display manager
that allow it to be more conveniently used with the ATT 5620 terminals (for
those of us still trying to use this device for mged ;-).  Now, When you are
prompted for the tty device for the tek display, give the name of the terminal
pseudo-device for the window running the "tek4014" emulator on the blit,
followed by a space and "-b".  This can be thought of as the "blit" flag to
the tty device.  You should be able to use the mouse to position the tektronix
cross-hair cursor, and typing a return will send the cursor position to mged.

<p>
The tek4014 emulator should be started with the "-e" option.

<p>
Lee
Path: adm!smoke!gwyn
From: Doug Gwyn &lt;gwyn@smoke.brl.mil&gt;
Newsgroups: comp.bugs.4bsd
Subject: SunOS 4.0 frexp() bug
Date: 6 Dec 90 21:34:06 GMT

<p>
We recently tried using a Sun-4 for the first time and immediately
discovered that frexp(0.0,...) goes into an infinite loop.  The
only SunOS source code I could find around here seems to indicate
that the frexp.c that I assume was used for the SPARC machine was
obtained via BSD, which is why I'm posting this here.

<p>
One wonders how frexp() could possibly have passed its pre-release
tests..
Date:     Thu, 6 Dec 90 20:08:44 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  mged big-E working (again)

<p>
I'm pleased to be able to report that MGED's big-E command
in the current development MGED is working again.

<p>
You may recall that when I added the NMG support ("ev" command)
to MGED, using the new tree-walker, I broke the big-E command.

<p>
What I have done is to place a private copy of the old tree walker into
the big-E module (proc_reg.c), and given it some private new subroutine
names, so that the big-E command can continue to operate exactly as it
had done in the past, while the remainder of the software can
remain switched over to the new tree walker.
Not the prettiest solution, but pragmatic.

<p>
Now I don't have to worry about whether the NMG support will provide
the big-E capability immediately, or not. This also means that when the
handful of known MGED bugs have all been addressed, this new MGED can be
put in the hands of the user community for testing (breaking), well
before the release cycle gets really underway.

<p>
	Onwards!
	 -Mike
Date:     Thu, 13 Dec 90 16:04:45 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  Multiple Processors

<p>
&gt; I have written an application that uses raytracing and I
&gt; am interested in utilizing multiple processors.  What do
&gt; I need to do to implement something similar to the -P
&gt; option on rt?

<p>
There is only a little bit extra that you will have to add to your
main program, in order to cooperate with the multi-processor support
already provided in LIBRT.  The global RT resource structures will
need initialized, as seen in this excerpt from rt/rt.c:

<p>
	/*
	 *  Handle parallel initialization, if applicable.
	 */
	if( npsw &gt; 1 )  {
		rt_g.rtg_parallel = 1;
		fprintf(stderr,"rt:  running with %d processors\n", npsw );
	} else
		rt_g.rtg_parallel = 0;
	RES_INIT( &rt_g.res_syscall );
	RES_INIT( &rt_g.res_worker );
	RES_INIT( &rt_g.res_stats );
	RES_INIT( &rt_g.res_results );
	RES_INIT( &rt_g.res_model );
	/*
	 *  Do not use rt_log() or rt_malloc() before this point!
	 */

<p>
However, there remains the issue of handling the dispatching of
work, and the accumulation of results, within your program.
The program RT uses a "self-dispatcher" algorithm, centered on
the semaphored variable "cur_pixel", to manage sharing the work
between the processors.  Here, whenever a processor is ready for
more work, it takes the next pixel in the sceen.  Thus, the
granularity of the parallelism is at the pixel leve.
This can be seen in this excerpt from rt/worker.c:

<p>
/*
 *  Compute a run of pixels, in parallel if the hardware permits it.
 *
 */
void
do_run( a, b )
{
	cur_pixel = a;
	last_pixel = b;

<p>
	if( !rt_g.rtg_parallel )  {
		/*
		 * SERIAL case -- one CPU does all the work.
		 */
		worker();
		return;
	}

<p>
	/*
	 *  Parallel case.
	 */
	nworkers = 0;
	rt_parallel( worker, npsw );
}

<p>
/*
 *  Compute one pixel, and store it.
 */
void
worker()
{
	LOCAL struct application a;
	LOCAL vect_t point;		/* Ref point on eye or view plane */
	LOCAL vect_t colorsum;
	register int com;
	int	cpu;			/* our CPU (PSW) number */

<p>
	RES_ACQUIRE( &rt_g.res_worker );
	cpu = nworkers++;
	RES_RELEASE( &rt_g.res_worker );

<p>
	resource[cpu].re_cpu = cpu;
	resource[cpu].re_magic = RESOURCE_MAGIC;
	rand_init( resource[cpu].re_randptr, cpu );

<p>
	while(1)  {
		RES_ACQUIRE( &rt_g.res_worker );
		com = cur_pixel++;
		RES_RELEASE( &rt_g.res_worker );

<p>
		if( com &gt; last_pixel )
			break;

<p>
		/* Note: ap.... may not be valid until first time here */
		a = ap;				/* struct copy */
		a.a_resource = &resource[cpu];

<p>
		....
		a.a_level = 0;		/* recursion level */
		a.a_purpose = "main ray";
		rt_shootray( &a );
		....
		view_pixel( &a );
		if( a.a_x == width-1 )
			view_eol( &a );		/* End of scan line */
	}
	RES_ACQUIRE( &rt_g.res_worker );
	nworkers--;
	RES_RELEASE( &rt_g.res_worker );
}

<p>
The code above handles the dispatching of the work. This leaves the
issue of disposing of the results. When RT sends it's results
(unbuffered) to a framebuffer, this fragment of code from rt/view.c is
used:

<p>
/*
 *  Arrange to have the pixel output.
 */
void
view_pixel(ap)
register struct application *ap;
{
	....
	if( fbp != FBIO_NULL )  {
		/* Framebuffer output */
		RES_ACQUIRE( &rt_g.res_syscall );
		fb_write( fbp, ap-&gt;a_x, ap-&gt;a_y, (char *)p, 1 );
		RES_RELEASE( &rt_g.res_syscall );
	}

<p>
If the results are buffered (either for framebuffer or file output)
the results are accumulated in a pixel array called "scanbuf".
The access to scanbuf needs to be single-threaded, because most
RISC machines do not have hardware byte-splice capability:

<p>
	/*
	 *  Store results into pixel buffer.
	 *  Don't depend on interlocked hardware byte-splice.
	 *  Need to protect scanline[].sl_left when in parallel mode.
	 */

<p>
	case BUFMODE_DYNAMIC:
		slp = &scanline[ap-&gt;a_y];
		RES_ACQUIRE( &rt_g.res_results );
		if( slp-&gt;sl_buf == (char *)0 )  {
			slp-&gt;sl_buf = rt_calloc( width, 3, "sl_buf" );
		}
		pixelp = slp-&gt;sl_buf+(ap-&gt;a_x*3);
		*pixelp++ = r ;
		*pixelp++ = g ;
		*pixelp++ = b ;
		if( --(slp-&gt;sl_left) &lt;= 0 )
			do_eol = 1;
		RES_RELEASE( &rt_g.res_results );
		break;

<p>
followed a little later by the actual output section:

<p>
	case BUFMODE_DYNAMIC:
		if( fbp != FBIO_NULL )  {
			RES_ACQUIRE( &rt_g.res_syscall );
			fb_write( fbp, 0, ap-&gt;a_y,
			    scanline[ap-&gt;a_y].sl_buf, width );
			RES_RELEASE( &rt_g.res_syscall );
		}
		if( outfp != NULL )  {
			int	count;

<p>
			RES_ACQUIRE( &rt_g.res_syscall );
			fseek( outfp, ap-&gt;a_y*width*3L, 0 );
			count = fwrite( scanline[ap-&gt;a_y].sl_buf,
				sizeof(char), width*3, outfp );
			RES_RELEASE( &rt_g.res_syscall );
			if( count != width*3 )
				rt_bomb("view_pixel:  fwrite failure\n");
		}

<p>
Thus, you can see that the RT application makes use of these semaphore
variables:

<p>
res_worker		to protect work-dispatcher variables
res_results		to protect scanline[] and scanbuf[]
res_syscall		to protect system calls (mainly I/O)

<p>
(The LIBRT library internally makes use of res_syscall and res_model).

<p>
The RES_ASCUIRE() macro begins a critical section, and the RES_RELEASE()
macro ends the critical section.

<p>
If you are generally familiar with parallel programming, this should be
enough information to get you going.  If you would like some additional
background on parallel programming, Cray has a small, excellent
publication (number SR-222) that I highly recommend as introductory
reading.  To relate the terminology used, this chart should help:

<p>
	BRL-CAD Routine		Cray Routine
	===============		============
	RES_INIT		LOCKASGN
	RES_ACQUIRE		LOCKON
	RES_RELEASE		LOCKOFF
	rt_parallel		TSKSTART plus TSKWAIT

<p>
I feel compelled to caution at this point that some algorithms lend
themselves to parallelism much more readily than others do, so the
amount of effort required to parallelize your application may vary.
If, after reading the Cray manual, you feel that you need some additional
guidance, I'd be willing to get together with you and go over your
application.

<p>
	Best,
	 -Mike
Date:     Wed, 26 Dec 90 19:54:42 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  cad/Cakefile.lib fix

<p>
Dear John -

<p>
Thanks for your bug report about installing BRL-CAD Release 3.7 on your
SGI 4D/210VGX.

<p>
In SGI's IRIX 3.3.1, the object-file archiver was modified, necessitating
this matching change to the file cad/Cakefile.lib.  This information
should be added to the errata sheet for Release 3.7;  it has already been
incorporated in the sources for Release 4.0.

<p>
My notes regarding this change were:
  "According to the documentation, the "u" option to AR is a modifier
  to be applied to the "r" command, rather than a real command in
  it's own right.  While this has worked fine for a decade or more,
  it broke with SGI Release 3.3.1, sigh.
  Might as well be standard."

<p>
The fix is to change line 41, e.g.:

<p>
41c41
&lt;       AR u PRODUCTS OBJ EXTRA_OBJ
---
&gt;       AR r PRODUCTS OBJ EXTRA_OBJ

<p>
Here is the context diff:

<p>
*** 38,44 ****

<p>
  PRODUCTS::    EXTRA_OBJ OBJ
        rm -f PRODUCTS; EXTRA_SETUP
!       AR u PRODUCTS OBJ EXTRA_OBJ
        RANLIB PRODUCTS

<p>
--- 38,44 ----

<p>
  PRODUCTS::    EXTRA_OBJ OBJ
        rm -f PRODUCTS; EXTRA_SETUP
!       AR r PRODUCTS OBJ EXTRA_OBJ
        RANLIB PRODUCTS

<p>
Best,
 -Mike
Date:     Wed, 19 Dec 90 6:37:18 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  New SGI 4D libfb: parallel!

<p>
This evening I removed the bug-check code in libfb/if_4d.c which
checked to make sure that only single-thread (uniprocessor) programs
would write graphics directly to the SGI screen.  This had been
necessary because of a long-standing problem in libgl.

<p>
In IRIX 3.3.1, the libgl bug no longer exists, and now parallel
libfb programs are free to write to the framebuffer in parallel,
provided of course that framebuffer operations are performed in
a critical section (i.e. bracked by RES_ACQUIRE(syscall)
and RES_RELEASE(syscall) operations).

<p>
I have also modified the defaults so that the RT program on the SGI
now defaults to using all the CPUs, rather than just one, since it
will now work.

<p>
Considering that SGI makes multi-processor graphics systems, I shudder to
think how many years it has taken to get multi-processor graphics
capability working!  But, at least it is here now.

<p>
...Working hard on BRL-CAD Release 4.0...
	Best,
	 -Mike
Date:     Wed, 26 Dec 90 19:54:42 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  cad/Cakefile.lib fix

<p>
Dear John -

<p>
Thanks for your bug report about installing BRL-CAD Release 3.7 on your
SGI 4D/210VGX.

<p>
In SGI's IRIX 3.3.1, the object-file archiver was modified, necessitating
this matching change to the file cad/Cakefile.lib.  This information
should be added to the errata sheet for Release 3.7;  it has already been
incorporated in the sources for Release 4.0.

<p>
My notes regarding this change were:
  "According to the documentation, the "u" option to AR is a modifier
  to be applied to the "r" command, rather than a real command in
  it's own right.  While this has worked fine for a decade or more,
  it broke with SGI Release 3.3.1, sigh.
  Might as well be standard."

<p>
The fix is to change line 41, e.g.:

<p>
41c41
&lt;       AR u PRODUCTS OBJ EXTRA_OBJ
---
&gt;       AR r PRODUCTS OBJ EXTRA_OBJ

<p>
Here is the context diff:

<p>
*** 38,44 ****

<p>
  PRODUCTS::    EXTRA_OBJ OBJ
        rm -f PRODUCTS; EXTRA_SETUP
!       AR u PRODUCTS OBJ EXTRA_OBJ
        RANLIB PRODUCTS

<p>
--- 38,44 ----

<p>
  PRODUCTS::    EXTRA_OBJ OBJ
        rm -f PRODUCTS; EXTRA_SETUP
!       AR r PRODUCTS OBJ EXTRA_OBJ
        RANLIB PRODUCTS

<p>
Best,
 -Mike
Date:     Thu, 10 Jan 91 22:27:24 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  fbclear -c

<p>
I have thought about this a lot, (and I've been burned by it a lot
lately), so I have reversed the sense of the -c flag on fbclear.
By default, only the color is sent.  If -c is given, then
cmap and zoom/pan are reset as well.

<p>
To prevent novices from getting surprised by this change in behavior,
in default mode, if the colormap or zoom are not normal, a message
is printed.

<p>
Not clearing the cmap (especially) is much more consistent with the
growing trend to use gamma correction in the colormaps.
My SGI monitor certainly needs it, and it is tiresome to have to keep
putting the gamma ramp back in.

<p>
	Comments?
	 -Mike
Date:     Fri, 11 Jan 91 9:48:21 EST
From:     Patrick Jonke &lt;jonke@BRL.MIL&gt;
Subject:  MGED Question

<p>
Is it possible for two people working on different terminals
to edit the same mged file simultaneously?  The mged file in
question is located on a file server, and each of the terminals
is a Personal Iris.
Date:     Fri, 11 Jan 91 11:12:46 EST
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
Subject:  Re:  MGED Question

<p>
Patrick Jonke asks what if 2 people on different terminals are editing
the same mged file.  It appears to me that you might end up with some
of the changes made by each!  (This would be different from writing
out a new file with the editors "e", "jove", etc., where the version
which is saved last blows away all changes made in the version saved
earlier.)

<p>
I tested by editing the same mged file in

<p>
1. Two windows on a Silicon Graphics terminal (file was on a server)
2. Two MPX windows on vmb.brl.mil .  Here, I then tried editing a file
   consisting only of 2 solids (call them "original" and "original2").
   In the first window, I said "mv original first", and in the second
   window I said "mv original2 second".  When I have done this, I have
   solids called "first" and "original2" in the first window, and solids
   called "original" and "second" in the bottom window.  Then when I
   exited both MGED runs, and then came back into MGED, I found that the
   solids were called "first" and "second"!  In other words, when I run
   MGED, I seem to have a working version of the file AND a saved version
   which gets updated immediately; and these versions should be the same
   if only one person is running MGED on that file.
Date:     Fri, 11 Jan 91 14:01:47 EST
From:     "Daniel C. Dender" (SE|andr) &lt;dender@BRL.MIL&gt;
Subject:  Re:  MGED Question

<p>
Carl Moore writes:

<p>
&gt; Patrick Jonke asks what if 2 people on different terminals are editing
&gt; the same mged file.  It appears to me that you might end up with some
&gt; of the changes made by each!  (This would be different from writing
&gt; out a new file with the editors "e", "jove", etc., where the version
&gt; which is saved last blows away all changes made in the version saved
&gt; earlier.)

<p>
[ and then details his experiment. ]

<p>
Carl and Patrick,

<p>
Unfortuneately, it is possible to have two people work on an MGED file
at the same time. The reason it is unfortunate is that the two sessions
both write into the same database, unaware of the changes made by the
other. There is no file locking done by MGED to ensure that only one
person works on a database at one time, and all changes are made
directly in the binary database according to what each MGED session
thinks the database looks like. So Carl is right, some of the changes
made by each can be reflected in the new database, but not all and not
in any reliable fashion.

<p>
The important point is that the two sessions are unaware of the state
of the database after changes made by the other. Carl's example is
misleading in that it seems that both sets of changes are retained.
This is due to the simple nature of his experiment, in that the quantity
changed was simply the name field in two objects that already existed
in both databases. If instead the example had looked at the two sessions
each adding new objects to the database then the same results would
not have been seen. Only one set of changes, or one set plus the
fragmented end of the second set (which would probably show up as an
error), would be seen then.

<p>
So the rule (at least for now) is don't let it happen!

<p>
Dan Dender

<p>
Date:     Fri, 11 Jan 91 14:33:15 EST
From:     Carl Moore (VLD/VMB) &lt;cmoore@BRL.MIL&gt;
Subject:  Re:  MGED Question

<p>
Yes, I see the item about my experiment changing only the name fields
of existing solids.  But, to respond to Dan Dender, I did not intend
to point out that both sets of changes are retained.  It so happened
that no change I made in my test cancelled another change, but the
saved file still was not the same as either working file at the end
of the respective, simultaneous MGED sessions.

<p>
Therefore, I tried an even simpler experiment.  I made a file with just
one solid, called "original", then I ran MGED in 2 windows.  In the first
window, I said "mv original first", and in the second window, I then said
"mv original second".  At this point "tab *" showed the solid to be called
"second" because that was the last name change for that solid in the saved
file (database), but the working files still had "first" and "second" as
the respective names for that solid.  When I left these MGED sessions and
then re-entered MGED, the solid was called "second".

<p>
So as you have already heard:  Know what you are doing if you want to
run more than one MGED at the same time on the same file, or don't do it!
Date:     Fri, 11 Jan 91 16:21:09 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  MGED Question

<p>
Knowing what MGED is doing inside, the answer is pretty clearly no,
i.e. only one MGED can edit a single database at a time.

<p>
While you can get away with some things using multiple MGEDs, the
problems will only get worse in the next release where more info is
cached in memory.  Dan brings up an important point though, perhaps
file locking should be used so that any additional MGEDs come up in
Read-Only mode.

<p>
Alternately, if people thought that multiple simultaneous edits was a
really important thing, we might be able to construct a scheme with
locking and file stat'ing that would allow this.  However, there would
still be cases which would be hard, if not impossible, to handle (e.g.
in the middle of a solid or object edit, someone else modifies that same
object).

<p>
In general, I would suggest that you copy some or all of the database,
work seperately on those copies, and then merge the results back together.

<p>
- Phil
Date:     Thu, 17 Jan 91 17:57:09 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  brl on rs/6000

<p>
A couple of us independently tried to put BRL-CAD on the R6000
several months ago.  At that time the process was very difficult
due to numerous bugs in the C compiler and/or OS.  I don't remember
the AIX revision number back then.  It is likely to have gotten
better, but no one here has tried again recently.  I will take a
shot at testing our next release against it.

<p>
- Phil
Date:     Sat, 26 Jan 91 5:12:42 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  librt import/export

<p>
This evening I converted all the geometry modules over to the new
import/export interface.  This is already starting to have a simplifying
effect on some of the more difficult code elsewhere.
	-M
Date:     Tue, 29 Jan 91 0:33:07 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  new vlist structure

<p>
This evening, I instituted the new "chunky" vlist structures.
LIBRT and RT directories have been converted over,
but MGED will need some work.
Lee and I will continue on this Tuesday.
	Best,
	 -Mike
	id AA13004; Sun, 27 Jan 91 12:54:26 EST
Date: Sun, 27 Jan 91 12:54:26 EST
From: "Christopher T. Johnson" &lt;cjohnson@slc1.brl.mil&gt;
Message-Id: &lt;9101271754.AA13004@slc1.brl.mil&gt;
Subject: Mged projective mode, sgi-4d

<p>
Hello,

<p>
This weekend the development version of dm-4d (device manager for
sgi 4ds) was modified so that the perspective mode key (F3) toggled
through verious prospectives.

<p>
Originally the perspective key toggled between 90% perspective and
orthagonal.  This would simulate the -p90 and -p0 (or nothing) option
to rt.

<p>
I've changed the perspective key to toggle through 90,60,45,30 and
orthagonal projections.  On keyboards that have led indicators the
perspective light is lit in 90,60,45 and 30 degree modes.

<p>
This was done to allow for the previewing of rt anim scripts at
different prospectives.

<p>
	Chris
	id AA13012; Sun, 27 Jan 91 13:05:37 EST
Date: Sun, 27 Jan 91 13:05:37 EST
From: "Christopher T. Johnson" &lt;cjohnson@slc1.brl.mil&gt;
Subject: rtsrv et al

<p>
Mike, Paul,

<p>
After getting Paul's e-mail yesterday explaining how he had changed my
id on wizard and killed off the rtsrv to allow him to get work done on
wizard I started thinking about ways to allow users to keep remrt from
using a machine.

<p>
To this end I added to new commands to remrt
	hold host	Drop a host and hold from adding.
	resume host	Add a host and release any holds.

<p>
To stop an obnoxious rtsrv, do a ps -ef |grep rtsrv.  This will tell
where the remrt is coming from.

<p>
	rtsrv whale 4446 'hold wizard.brl.mil'

<p>
This command will cause the remrt on whale to drop wizard and to
ignore wizard until further notice.

<p>
	rtsrv whale 4446 'resume wizard.brl.mil'

<p>
This command will cause the remrt on whale to clear the hold on using
wizard and will start processing on wizard.  If the time is not
correct remrt will drop wizard at the next time check.

<p>
Thanks,
	Chris
Date:     Wed, 6 Feb 91 15:41:59 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  remrt: /tmp/public_cpus

<p>
REMRT's distributed raytracing server, named RTSRV, has gained a new
feature.  When starting up, it reads the file /tmp/public_cpus
to find out how many cpus on that system it may use.
The file contains a single number, in ASCII, on a line by itself.

<p>
If the number of public cpus is zero, RTSRV will not continue to run on that
machine.  If the number of public cpus is positive, RTSRV will use that many
cpus (not to exceed the number of physical cpus actually operating at
that time).  If the number of public cpus is negative, RTSRV will use
"all but" that many cpus.  For example, if public_cpus = -2 and
the system has 8 cpus, RTSRV will use 6 ("all but 2").
These semantics follow RT's -P (number of processors) option.

<p>
This makes it possible to use some, but not all, the resources of
a given machine for RTSRV.
	Best,
	 -Mike

<p>
Date:     Wed, 6 Feb 91 16:07:34 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  correction: /usr/tmp/public_cpus

<p>
Oops, wrong path name.  The public_cpus file actually lives in /usr/tmp,
so that it persists across reboots.
	Best,
	 -Mike
Date:     Thu, 7 Feb 91 0:51:58 EST
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
Subject:  ERIM solids

<p>
The first of the ERIM solids has been implemented.  More to come.

<p>
Lee
Date:     Mon, 11 Feb 91 17:13:30 EST
From:     "Robert J. Reschly Jr." &lt;reschly@BRL.MIL&gt;
Subject:  Re: correction: /usr/tmp/public_cpus

<p>

<p>
      Mike,

<p>
   It strikes me that this is something of a system configuration file
and should therefore live in {/, /usr/local/, ...}etc, especially if
this is something you envision having long term life (i.e. there for
months at a time).  If you don't want to clutter the main file systems
with this file, I hesitantly suggest /usr/brlcad/lib, though I have
never completely forgiven the folks who brought us /usr/lib/crontab....
This also protects it from those nice little housecleaning scripts.

<p>
   If you feel there must be a "public" version of this file, then
I still argue for the above, with rtserv using the more restrictive of
the two.

<p>
				Later,
				    Bob

<p>
Date:     Mon, 11 Feb 91 20:34:35 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  correction: /usr/tmp/public_cpus

<p>
A couple of items:

<p>
If the file does not exist, RTSRV will re-create it.

<p>
I think that it is important that this file be writable to
all users, and I expect that it might be updated pretty much at any time.

<p>
There really isn't any parallel for this kind of "configuration" file
in UNIX, and we needed something right away, so I just SWAGed it
and threw the file in /usr/tmp.

<p>
So far, we have managed to avoid having any system-specific configuration
files in /usr/brlcad, but I could live having them, if necessary.
I'm not sure what the "right" long term implementation should be.

<p>
	Thoughts?
	 -Mike
Date:     Tue, 12 Feb 91 9:39:30 EST
From:     Sue Muuss (VLD/ASB) &lt;sue@BRL.MIL&gt;
Subject:  Arbns

<p>
This morning I checked in a new set of asc2g and g2asc: this version supports
arbns.

<p>
				Cheers,

<p>
					Sue
Date:     Wed, 20 Feb 91 0:25:45 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  SGI 4d improvements

<p>
These new features have been added to the experimental MGED's SGI 4D
software:

<p>
*)  Can now move and resize MGED window.

<p>
*)  Note account for 5:4 aspect in NTSC mode, so that circles are round on TV.

<p>
*)  Clear full viewport in NTSC mode, to clean out other window
stuff that may have popped up in the interim (like libfb).

<p>
These may seem like minor nits, but resizing the window had never
worked. It seems that the SGI writeprotects all new bits added to
your window on resize or move until you make them writable with
scrmask().  Until now, a bit of trivia that had escaped me.

<p>
	Best,
	 -Mike
	(for cad@brl.mil) id AA01186; Wed, 20 Feb 91 23:41:23 +0100
From: Valter Cavecchia &lt;root@itnsg1.cineca.it&gt;
Subject: Some problems
Date: Wed, 20 Feb 91 23:41:21 MET
Organization: Laboratorio di Fisica Computazionale I.N.F.M.

<p>
I'm a novice user of brl-cad so please apologize...
I have compiled the package on a Silicon Graphics Personal Iris, it follows
the output of "hinv":

<p>
	1 12 MHZ IP6 Processor
	FPU: MIPS R2010A/R3010 VLSI Floating Point Chip Revision: 1.5
	CPU: MIPS R2000A/R3000 Processor Chip Revision: 1.6
	Data cache size: 8 Kbytes
	Instruction cache size: 16 Kbytes
	Main memory size: 12 Mbytes
	Integral Ethernet controller: Version 0
	Graphics board: GR1.1 Bit-plane, Z-buffer options installed
	Integral SCSI controller 0: Version WD33C93
	Tape drive: unit 2 on SCSI controller 0: QIC 150
	Disk drive: unit 3 on SCSI controller 0
	Disk drive: unit 1 on SCSI controller 0

<p>
and "uname -a":
	itnsg1 itnsg1 3.3.1 08201206 IP6

<p>
I found a problem compiling the sources, a lot of programs were linked
(using the default Cakefile) without the lgl_s library...

<p>
Now the REAL problems:
First, when I invoke mged I found the following errors regarding DIALDAEMON,
it is important? Is there any way to bypass this?

<p>
	BRL-CAD Release 3.5 Graphics Editor (MGED) Compilation 1
    	Mon Feb 18 22:10:03 MET 1991
    	root@itnsg1:/home/brl/mged

	attach (nu|tek|tek4109|ps|plot|sgi)[nu]? sgi
	ERROR #104  dbtext: ERR_NODIALDAEMON
	ATTACHING sgi (SGI 4d)
	The Enterprise and Shuttlecraft  (units=meters)
	ERROR #104  setdblights: ERR_NODIALDAEMON

<p>
But the major problem is that "fbed" core dumps with:
	Segmentation fault (core dumped)

<p>
And this seems a big problem to solve,
any experience?

<p>
Thanks a lot in advance,
	valter

<p>
p.s.:
	I made the kernel mods that you suggested.

<p>
--

<p>
 ---------------------------------------------------------------------------
|  Valter V. Cavecchia          | Bitnet:       cavecchi@itncisca           |
|  Centro di Fisica del C.N.R.  | Internet:     root@itnsg1.cineca.it       |
|  I-38050 Povo (TN) - Italy    | Decnet:       itnvax::cavecchia (37.65)   |
 ---------------------------------------------------------------------------

<p>
Date:     Wed, 20 Feb 91 21:57:16 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  Some problems

<p>
Valter -

<p>
Thank-you for the detailed bug report.  If your SGI machine does not
have the dial and button box, you can disable support for it by
editing the file Cakefile.defs, and changing the line that now reads:

<p>
#       define  MGED_CONFIG     GFLAG -DIR_KNOBS=8 -DIR_BUTTONS=32 -DDM_4D

<p>
to

<p>
#       define  MGED_CONFIG     GFLAG -DDM_4D

<p>
e.g., remove the definitions of IR_KNOBS and IR_BUTTONS.
Then:
	cd mged
	cake clobber
	cake

<p>
and you should have a working MGED that won't complain about ERROR #104.

<p>
I am not certain why FBED might dump core.  Several suggestions:

<p>
First, set your environment variable FB_FILE=/dev/debug and try again.
If that seems OK, then try FB_FILE=/dev/sgi and try again.
If you get a core dump again, please run SCRIPT, then inside the
script session, run "dbx fbed" (if FBED comes from another directory,
please use the full path to get to FBED, e.g., "dbx /usr/brlcad/bin/fbed").
Then, inside DBX, give the "where", "dump", and "quit" commands,
exit the script, and E-mail it to me.  That way I'll have some idea
how to advise you.

<p>
Do other framebuffer programs operate correctly, like "fbclear 200 0 200" ?

<p>
	Best,
	 -Mike
Date:     Sat, 23 Feb 91 5:27:04 EST
From:     Mike Muuss  &lt;mike@brl.mil&gt;
Subject:  Re:  BRL-CAD

<p>
OK, I've been prodded.   Here are the answers to your questions.

<p>
1)  There is some work in progress to read the solid modeling part
of IGES v.4 files.  In general, IGES files contain *drawings*, not
solid models.  BRL-CAD is a solid modeling system, and not a drafting
system.  We do read quite a number of other solid modeling formats.
(Air Force "PATCH" format, Navy "BSSD" format, etc), and a number
of commercial system interfaces are underway.

<p>
2)  What is included?  17 Mbytes of source code and reference material.
See below for a hint.

<p>
3)  We only send source, and that one set of source runs on all the supported
platforms.  Suns and SGIs are supported.  One tape is all you have to send.

<p>
4)  Basicly, we want you to say "we agree to the terms", and give us
a hint of (a..d).  One sentence each.  For our "brag sheet" to HQ,
never sent to non-Gov't people.

<p>
5)  There are copies at Langley, but we'd like to put you on our mailing
list anyway.

<p>
6)  We are getting ready to have another BRL-CAD Symposium.
Contact &lt;keith@brl.mil&gt; for info.

<p>
	Best,
	 -Mike

<p>
-------------- Attachment 1, Langley sites:

<p>
--- 83 ---
NASA Langley Research Center
Space Systems Division
Mail Stop 365
Hampton, VA  23665-5225
ATTN: John Rehder

<p>
SGI cartridge

<p>
-------------- Attachment 2, "the blurb":

<p>
The BRL-CAD Package includes a powerful solid modeling capability and
a network-distributed image-processing capability. This software is now
running at over 400 sites.  It has been distributed to 42 acedemic
institutions in twenty states and four contries. 75 different businesses
have requested and received the software including 23 Fortune 500
companies. 16 government organizations representing all three services,
NSA, NASA, NBS and the Veterns Administration are running the code.
Three of the four national laboratories have copies of the BRL CAD
package.

<p>
BRL-CAD started in 1979 as a task to provide an interactive graphics
editor for the BRL vehicle-description data base. Today the package
totals more than 150,00 lines of "C" source code. It runs under UNIX and
is supported over more than a dozen product lines from Sun Workstations
to the Cray 2. The package includes:

<p>
	A Solid geometric editor
	The Ray tracing library
	Two Lighting models
	Many image-handling, data-comparison, and other supporting utilities

<p>
In terms of geometrical representation of data, BRL-CAD supports:

<p>
	The original Constructive Solid Geometry (CSG) BRL database.

<p>
	Extensions to include solids made from collections of
	Uniform B-Spline Surfaces as well as
	Non-Uniform Rational B-Spline [NURB] Surfaces.

<p>
	A facetted data representation.

<p>
It supports association of material (and other attribute properties)
with geometry which is critical to subsequent applications codes.
It supports a set of extensible interfaces by means of which geometry
(and attribute data) are passed to applications.

<p>
Applications linked to BRL-CAD:

<p>
o Weights and Moments-of-Inertia
o Optical Image Generation (including specular/diffuse reflection,
	refraction, and multiple light sources, animation, interference)
o Bistatic laser analysis
o A number of Synthetic Aperture Radar Codes (including codes due to ERIM)
o Acoustic model predictions
o High-Energy Laser Damage
o High-Power Microwave Damage
o An array of V/L Codes
o Neutron Transport Code
o Link to PATRAN [TM] and hence to ADINA, EPIC-2, NASTRAN, etc.
	for structural/stress analysis
o X-Ray calculation

<p>
For more details about what geometric models are useful for, see M.
Muuss, ``Understanding the Preparation and Analysis of Solid Models'',
in ``Techniques for Computer Graphics'', ed: Rogers & Earnshaw, Springer
Verlag, 1987.

<p>
To obtain a copy of the BRL CAD Package distribution, you must send
enough magnetic tape for 20 Mbytes of data. Standard nine-track
half-inch magtape is the strongly preferred format, and can be written
at either 1600 or 6250 bpi, in TAR format with 10k byte records. For
sites with no half-inch tape drives, Silicon Graphics and SUN tape
cartridges can also be accommodated. With your tape, you must also
enclose a letter indicating

<p>
(a) who you are,
(b) what the BRL CAD package is to be used for,
(c) the equipment and operating system(s) you plan on using,
(d) that you agree to the conditions listed below.

<p>
This software is an unpublished work that is not generally available to
the public, except through the terms of this limited distribution.
The United States Department of the Army grants a royalty-free,
nonexclusive, nontransferable license and right to use, free of charge,
with the following terms and conditions:

<p>
1.  The BRL CAD package source files will not be disclosed to third
parties.  BRL needs to know who has what, and what it is being used for.

<p>
2.  BRL will be credited should the software be used in a product or written
about in any publication.  BRL will be referenced as the original
source in any advertisements.

<p>
3.  The software is provided "as is", without warranty by BRL.
In no event shall BRL be liable for any loss or for any indirect,
special, punitive, exemplary, incidental, or consequential damages
arising from use, possession, or performance of the software.

<p>
4.  When bugs or problems are found, you will make a reasonable effort
to report them to BRL.

<p>
5.  Before using the software at additional sites, or for permission to
use this work as part of a commercial package, you agree to first obtain
authorization from BRL.

<p>
6.  You will own full rights to any databases or images you create with this
package.

<p>
All requests should be sent to:

<p>
	Keith Applin
	Ballistic Research Lab
	APG, MD  21005-5066

<p>

<p>

<p>
Best Wishes,
 -Mike Muuss

<p>
Advanced Computer Systems
ArpaNet:  &lt;Mike @ BRL.ARPA&gt;
Date:     Thu, 28 Feb 91 15:58:07 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  RT options

<p>
This afternoon, I added a few new options to RT, at the request of
several users.  First, the "-c" option, which allows any RT animation
script command to be given on the command line. For example,

<p>
	rt -s64 -c "set bounces=7" -c "set" moss.g all.g

<p>
allows the maximum number of ray bounces to be changed (first -c
option), and the current viewing-model variables to be displayed (using
the -c "set" command).  Another example is:

<p>
	rt -s64 -c "set background=.25,0,.5" moss.g all.g

<p>
which sets the background to the current default purple background,
using normalized intensities in the range 0 to 1. This can also be
accomplished with a shorthand option, using RGB values in the range
(0..255):

<p>
	rt -s64 -C 63/0/127 moss.g all.g

<p>
Note that any non-numeric characters can be used as value separators.
The comma and slash are the two I find myself using most often.

<p>
The -c option will be especially useful for the radar codes built as
RT view modules, as it will now allow access to all the
application-specific variables from the command line.  Traditionally,
they could only be set in an animation script, which was not always
convenient.

<p>
On a related subject, I am considering changing the default background
color in RT from purple to black (0/0/1).  If you have an objection to
this, please send me E-mail by 6-March.

<p>
	Best,
	 -Mike
Date:     Mon, 4 Mar 91 21:35:16 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  RT options

<p>
The 0/0/1 choice is so that the checkpoint/restart code can tell the
difference between unwritten pixels in the middle of the image
(UNIX zero-fills unwritten sections of a disk file), and background
pixels.  This prevents having to recompute all black background pixels
on a restart.

<p>
The choice of 0/0/1 is because the eye is less sensitive to blue,
so that keen-eyed watchers would be less likely to see it than, say,
0/1/0.

<p>
	Best,
	 -Mike
Date:     Tue, 5 Mar 91 3:11:36 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  RT options

<p>
I'm not sure I understand yet.  Yes, REMRT (in particular) does
seek around in the file, and gets big black gaps where CPUs have
not yet answered.

<p>
RT, when running in parallel (BUFMODE_DYNAMIC) also seeks around
in the file, as each scanline is completed.

<p>
I don't see any difference for compositing, as you would just
	pixmatte foo.pix -C0/0/1 stuff
rather than
	pixmatte foo.pix -C0/0/0 stuff
It would just be a different number to type.

<p>
Visually, 0/0/1 is indistinguishable from black 0,0,0 -vs- 0,0,0.0039
in floating point format.  (I've been using slashes for RGB values,
and commas for 0-1 normalized intensities, although the number parser
does not care).

<p>
So, please help me understand why 0/0/0 would be better than 0/0/1,
and how I should deal with the checkpoint restart issue then.
I'm genuinely concerned that I've missed some important point!
	Best,
	 -Mike
Date:     Wed, 6 Mar 91 13:17:37 EST
From:     Paul Tanenbaum &lt;pjt@BRL.MIL&gt;
Subject:  Re: FBZOOM(1) bug

<p>

<p>
Mike,
     I've fixed the VI/JOVE commands, the help menu, and the man page.
I also took you up on your suggestion, and added the -T option and the
'T' command, which toggle the sense of the pan commands.  The output
line now displays an indication whether you are moving the window or
the image.
    As for the choice of option flags... because you said that there
are two camps as far as this panning thing, I thought that eventually
several of the BRL-CAD utilities etc. might support the same kind of
user-selectable behavior.  To facilitate potential standardization,
I found a flag (viz. -T) which does not show up in util/*.1 so that
any other routines that acquire this functionality might use the
same flag.  If this ever came to pass, I guess it would end up in
brlcad.1 as well.
     +++paul

<p>
Date:     Wed, 6 Mar 91 21:02:35 EST
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  IGES opinion from net

<p>
FYI, a good terse summary of IGES.  Not entirely accurate, but close.
	-M

<p>
----- Forwarded message # 1:

<p>
From: Bret Strain &lt;brets@hpnmdla.hp.com&gt;
Newsgroups: comp.graphics
Subject: Re: IGES
Date: 6 Mar 91 16:09:55 GMT

<p>
&gt;In comp.graphics, pdbourke@ccu1.aukuni.ac.nz (Bourke) writes:
&gt;
&gt;    Could someone please supply me with information on the IGES graphics
&gt;    file format. Like, who developed it, what are its strong points,
&gt;    what are its problems. How successful is it...etc...

<p>
IGES (Initial Graphics Exchange Specification)  Current revision 5.0.

<p>
Developed by a committee of representitives of the CAE/CAD/CAM industry.

<p>
Published by the National Institute of Standards and Technology, U.S.
Department of Commerce.

<p>
Contact: Nancy Flower (703) 698-9600 extension 325 to order a spec.

<p>
Its primary use is to interchange design data and annotation for
(primarily) mechnical 2D and some 3D databases.

<p>
It is a well documented standard, and it is in common use with
mechanical CAD/CAM systems as well as some FE analysis packages.

<p>
The standard is not perfect.  It does not transfer 3D solid geometry.
It has a reasonbly rich specification in which many CAD/CAM systems only
implement a subset of its definition.

<p>
Strong points:

<p>
Documented standard.
Well accepted.

<p>
Weak points:

<p>
Like all standards, the semantics (based on implementations I've
seen) are not absolutely robust.
Does not handle 3D solid geometry.
The standard is "rich" (i.e. complex in many ways).

<p>
----- End of forwarded messages
Date:     Fri, 8 Mar 91 10:45:14 EST
From:     Earl Weaver (VLD/ASB) &lt;earl@BRL.MIL&gt;
Subject:  Re:  IGES opinion from net

<p>
Perhaps a little more details on the "inaccuracies" is
in order.

<p>
IGES 5.0 addresses other applications as well as mechanical
(electrical, architectural, piping...)

<p>
It DOES handle 3D solid geometry, but not all 3D solid
geometry.  For CSG geometry, it handles only a subset of
all primitives  and booleans used in solid modeling packages.
It handles the "block", "right angular wedge", "right circular
cylinder", "right circular cone frustum", "sphere", "torus"
(only circular cross-sectioned torus), "ellipsoid", "solid of
revolution", "solid of linear extrusion", boolean tree (union,
intersection, subtraction), solid assembly, and solid instance.
For B-rep, it should handle most models (as long as there are
IGES entities for the surface types; IGES addresses most of
those, I believe).

<p>
We are planning on working with IGES to implement extentions
to the primitive set such that the cones and cylinders
would be more general (corresponding to the BRLCAD TGC),
and adding a general polyhedron, and an ARB8.
Date:     Fri, 8 Mar 91 15:04:34 EST
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  plot-fb

<p>
It is called "pl-fb" now (since Jan '88) and it does work into any
frame buffer - including the SGI.  On the SGI though, there is also
"pl-sgi" which allows you to rotate plot files around and such.
See also: plrot, pl-pl, pl-ps, pldebug.

<p>
- Phil
Date:     Fri, 8 Mar 91 20:13:12 EST
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  IGES solids

<p>
I have no information on the ACAD converter.  I know they were working
on it.  It is unclear how they convert their Bezier patches into
solids, since one patch is unlikely to enclose a volume.

<p>
Intergraph is working on a converter, under contract to US Army TACOM.
Progress is slow, but they should have something by next year.

<p>
I don't see how the IGES support would help.  Both of these activities
have copies of LIBWDB, which gives them the ability to create any
kind of geometry that BRL-CAD supports.  The main difficulties have
been in (a) arranging approximations for solids they may have that
BRL-CAD does not have [a minor problem], and (b) determining how to
infer topological data from DRAWINGS which are *not* solid models,
in order to create a set of solids suitable for use in BRL-CAD.

<p>
There are a number of major extensions to the NMG work, to permit
NMG objects to have trimmed-NURBS faces, currently in progress.
This will eliminate all further problems of type (a) above.
The problem in (b) is hard, and in general, can't be solved.
As more people start building true solid models, this will
fade in importance.

<p>
Does this explanation help?  If there is some specific conversion task
that you face, perhaps I can suggest how you could do it using LIBWDB.
Rest assured that we do have a serious long-term interest in being able
to import models from commercial systems.  Right now, given current
priorities and funding, that won't be totally finished until FY93
or beyond.  (My biggest problem at the moment is that DoD has been in
a total hiring freeze condition for &gt; 1.5 years now).

<p>
	Best,
	 -Mike
From: "David R. Blythe" &lt;drb@eecg.toronto.edu&gt;
Newsgroups: comp.graphics.visualization
Subject: Re: apE and AVS pricing
Date: 14 Mar 91 04:32:02 GMT

<p>
In article &lt;38945@netnews.upenn.edu&gt; joe@retina.anatomy.upenn.edu (Joseph Panico) writes:
&gt;in MOVIE.BYU format. Where can I get MOVIE.BYU and the data formats for
&gt;both MOVIE.BYU and Wavefront's personal visualizer?
&gt;
&gt;                           Joe Panico
&gt;			   joe@retina.anatomy.upenn.edu

<p>
The movie.byu geometry file format looks like this:

<p>
	write(iunit,80) npn,njn,nptn,nedge
	write(iunit,80) ((npl(i,j),i=1,2),j=1,npn)
	write(iunit,100) ((x(i,j),i=1,3),j=1,njn)
	write(iunit,80) (jp(i),i=1,nedge)
 80	format(10i8)
 100	format(6e12.5)

<p>

<p>
where npn = number of parts (geometric objects)
      njn = number of nodes (total number of vertices)
      nptn = number of polygons (total over all parts)
      nedge = number of edges (total over all polygons in all parts)
      npl = array of pairs of indices into connectivity array for
	    start polygon node and end polygon node for each part
	    (if there is 1 part then it is a single line = 1 and nedge)
      x   = array of 3D vertices
      jp  = connectivity array - indices of vertices in x array
		making up a polygon with a negative index indicating the last
		vertex of a polygon  (an n-sided polygon would have n entries in
		the connectivity array and the n-th entry would be negated).

<p>
I have seen a number of programs that understand this format so its probably
worth knowing.  So does anybody know the file formats for the personal
visualizer?
	david blythe
	ontario centre for large scale computation
	drb@clsc.utoronto.ca
From: Gautam Mehrotra &lt;gautamm@ncsa.uiuc.edu&gt;
Newsgroups: comp.graphics.visualization
Subject: Wavefront's File format( was Re: apE and AVS pricing )
Date: 14 Mar 91 06:11:23 GMT

<p>
In article &lt;1991Mar13.233202.25268@jarvis.csri.toronto.edu&gt; drb@eecg.toronto.edu (David R. Blythe) writes:
&gt;In article &lt;38945@netnews.upenn.edu&gt; joe@retina.anatomy.upenn.edu (Joseph Panico) writes:
&gt;&gt;in MOVIE.BYU format. Where can I get MOVIE.BYU and the data formats for
&gt;&gt;both MOVIE.BYU and Wavefront's personal visualizer?
&gt;&gt;
&gt;&gt;                           Joe Panico
[ description of MOVIE&gt;BYU's format deleted]
&gt;I have seen a number of programs that understand this format so its probably
&gt;worth knowing.  So does anybody know the file formats for the personal
&gt;visualizer?
&gt;	david blythe

<p>
	Matthew Arrott posted a description of the format some time
back. [ The Subject header on his article was mysteriously missing
..].  I am posting a copy for those who missed it .....

<p>
Matt's article follows ...
-----------------------------------------------------------

<p>
If I am not mistaken one can call both institutions for this information.

<p>
The wavefront object format, if I remember correctly is the same as
their advanced animation package.  That is as follows:

<p>

<p>
#  This is a comment line
#
#  One moviable object per file.  In other words, a file is the atomic
#    unit of a rigid body system
#  The UNIX directory structure is used as the database structure
#
#  "\" The backlash character is used for line continuation
#  "!" is used as an end of line comment

<p>
o square  ! object name : Not used in the advanced animation package [optional]

<p>
mtllib  my.mtl your.mtl project.mtl ...     ! material library search
					    ! path [optional]
maplib my.map your.map ...                    ! map library search path
					      ![optional]

<p>
usemtl red    ! current material : all subsequent geometry will be
	      ! assigned this material [optional]
usemap logo ! current map  : all subsequent geometry will be assigned
	    ! this map [optional]
usemap off   ! turn texture mapping off for subsequent geometry

<p>
# Maps are the definition of the application of textures to the material
# properties of the object :
#
#      the mapping of the texture to the materials of the object
#
# This definition of the material/texture relationship is not the
# definition of the uvw space of the
#   texture to the xyz space of the geometry.  That definition is
#   facilitated through texture verticies
#   which are dicussed shortly.
#
#  Material and Map files have there own formats
#  Material files are discussed after the object file.

<p>
s  1    ! smoothing group : average vertex normals for shared verticies
	!of the same smoothing group
s  off  ! turn smoothing  off

<p>
v  0.0  0.0  0.0     ! vertex position
v  1.0  0.0  0.0
v  1.0  1.0  0.0
v  0.0  1.0  0.0

<p>
vt  0.0  0.0  0.0    ! texture vertex position
vt  0.0  1.0  0.0
vt  1.0  1.0  0.0
vt  1.0  0.0  0.0

<p>
vn -1.0  -1.0  1.0  ! vertex normal : may override the smoothing notion,
		     !may need to be normalized
vn  1.0  -1.0  1.0
vn  1.0   1.0  1.0
vn  -1.0  1.0  1.0

<p>
p 1 2 3 4               ! a series of four points made up of four index
			! references to verticies ( 1 base )

l  1 2 3 4               ! a line made up of four points with the
			 !topology of  vertex 1 to 2 to 3 to 4

<p>
f  1 2 3 4               ! a face (polygon) made up of four verticies.
			 !Counter clockwise ordering

<p>
f  1/1 2/2 3/3 4/4   ! a face with index references to texture verticies

<p>
f  1/1/1 2/2/2 3/3/3 4/4/4   ! a face with index references to texture
			     !verticies and vertex normals

<p>
f  1//1 2//2 3//3 4//4           ! a face with index references to
				  ! vertex normals

<p>
f  -4 -3 -2 -1          ! a face using relative vertex referencing. "-N"
			! reads: use N vertex ago

<p>
# vertices, texture verticies, vertex normals, points, lines, and face
# can be intermixed as long
#   as the referenced stuff is defined before it is referenced.

<p>
Material file

<p>
#  special characters are the same.

<p>
newmtl  red
Ka  0.1 0.0 0.0         ! ambient color responce
Kd  0.4 0.0 0.0         ! diffuse color responce
Ks  0.4 0.0 0.0         ! spectular color
Ns  20                      ! spectular exponent
d  1.0                        ! dissolve   0.0 -- 1.0  transparent --
opaque
illum 1                     ! illumination model  0:color  1:diffuse ligthing
	 		    ! 2:diffuse and spectular lighting

<p>

<p>
------------------------------------

<p>
End of Matt's article ....

<p>

<p>
hope that helps

<p>
cheers,
gautam

<p>
---------------------------------------------------------

<p>
Gautam Mehrotra,

<p>
National Center for Supercomputing Applications, Univ of Illinois.
e-mail:	gautamm@ncsa.uiuc.edu

<p>
----------------------------------------------------------
Date:     Mon, 15 Apr 91 9:01:31 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
Subject:  Re:  vdeck?

<p>
|&gt; Just out of curiosity, what changed in VDECK?
Nothing really. Vdeck statically allocates arrays to hold info about objects
and solids; the length is configured with two #define constants NDIR and
MAXSOL respectively.  So, periodically as descriptions get larger, these
limits have to be enlarged and vdeck recompiled.  Since I always thought
that people weren't supposed to use GIFT, I haven't bothered to fix vdeck
to dynamically allocate the arrays.  Besides upping the array sizes, I
recently modified vdeck to allow configuration of these constants in the
Cakefile.

<p>
-Gary

<p>
          23 Apr 91 21:22 EDT
	id AA28296; Tue, 23 Apr 91 18:19:34 PDT
Date: Tue, 23 Apr 91 18:19:34 PDT
From: Roy Williams &lt;roy@sampson.ccsf.caltech.edu&gt;
Subject: color in brlcad

<p>

<p>
Is it possible to have a boolean operation such as intersection
between solids of different colors, with the ray tracer showing
both colors?

<p>
Thanx

<p>
Roy Williams
Caltech Concurrent Computation Project
Date:     Wed, 24 Apr 91 4:17:57 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  color in brlcad

<p>
Material properties, including color, are assigned to "regions" -
combinations with a special bit set indicating that they, and
everything below them in the model tree, make up one homogeneous
piece of material (not necessarily continuous).  Two regions should
not overlap, since two pieces of material can not occupy the same
physical space.  As such, there should not be any booleans other
than non-overlapping unions ("groups") above region nodes in the
tree.

<p>
If you do have any such overlaps, or non-union booleans above the
region nodes, the ray tracer will complain.  Which "material" (e.g.
color) you get in areas of conflict is somewhat non-deterministic.
If you do want to see e.g. an intersection specifically colored, you
should make a region node containing the intersection and assign it
the desired color.  [If the objects being intersected are themselves
regions, the ray tracer will print a warning during the "prep" phase,
and (by default) the material properties of the parent will "win"
and become the properties of the intersection.  Who wins is what the
inheritance property is about.]

<p>
I hope that helps.  In case you are just looking for overlaps, note
that there is the rtoverlap utility.

<p>
- Phil
Date:     Wed, 29 May 91 0:09:54 EDT
From:     Susan Muuss (VLD) &lt;sue@BRL.MIL&gt;
Subject:  RTRANGE

<p>
This weekend, on my own time, I wrote RTRANGE.  This program takes
advantage of the RTUIF I reported on at the BRL-CAD Symposium and
writes a UNIX-Plot file containing scanlines of range data.  Model
coordinates are preserved to permit overlays in MGED and to also
permit registration of the plot with other data.  This project was
inspired by presentations given by Dr. Judy Temperly and Bruce
Wallace during the SECAD Tutorial last week.  I hope that this
new BRL-CAD analysis tool will prove very useful to them in their
work.

<p>
			-Sue
Date:     Fri, 31 May 91 11:48:59 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  TIG-PACK and LIBPLOT3

<p>
While rolling things up for the release, I have moved all the TIG-PACK
routines (from LIBTIG) into LIBPLOT3.
	-Mike
Date:     Mon, 10 Jun 91 10:09:44 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
Subject:  Re:  [Dick Wiley - System: CAD on SunOS v4.1.1]

<p>
Dick,
	I have already addressed these problems in the current sources
(to be part of the next release of BRLCAD) though I haven't tested it yet
under SunOS 4.1.1 or on a Sparc, just 4.0.3 on a 3/80 where it compiles
cleanly.

<p>
|&gt; I have run into a couple of problems installing BRL-CAD on out SPARCserver
|&gt; 490 under SunOS v4.1.1.
|&gt;
|&gt; The major one comes from the following definitions in the include file
|&gt; /usr/include/sys/sysmacros.h:
|&gt;
|&gt; 	 * Major/minor device constructing/busting macros.
|&gt; 	/* minor part of a device */
|&gt; 	#define minor(x)        ((int)((x)&0377))
|&gt;
|&gt; 	/* major part of a device */
|&gt; 	#define major(x)        ((int)(((unsigned)(x)&gt;&gt;8)&0377))
|&gt;
|&gt; which conflict with the variables major and minor in fbed.c.  We get them
|&gt; because fbed.c includes fcntl.h, which includes sys/fcntlcom.h, which
|&gt; includes sys/stat.h, which includes sys/sysmacros.h.
I have changed the name of the variables "minor" and "major" in fbed.c to
"mindelta" and "majdelta".

<p>
|&gt; The other problem is that the following statements in fbed/std.h are
|&gt; causing the compiler to give 'illegal type combination' messages:
|&gt;
|&gt; typedef unsigned char   u_char;         /* unsigned integer types */
|&gt; typedef unsigned short  u_short;
|&gt; #ifdef  pdp11
|&gt; typedef long            u_long;         /* (not in Ritchie compiler) */
|&gt; #else
|&gt; typedef unsigned long   u_long;
|&gt; #endif
|&gt;
|&gt; These occur in fbed/fbed.c and fbed/execshell.c.
The following is from the current std.h:

<p>
#if defined(mips) && ! defined(IRIX3_3)
#define IRIX3_3         1       /* Assume running release 3.3 or later. */
#endif

<p>
#if ! IRIX3_3 || ! defined(__SYS_TYPES_H__)
/* Defined in &lt;sys/types.h&gt; under IRIX3.3. */
typedef unsigned char u_char;           /* unsigned integer types */
typedef unsigned short  u_short;

<p>
#ifdef  pdp11
typedef long            u_long;         /* (not in Ritchie compiler) */
#else
typedef unsigned long   u_long;
#endif
#endif

<p>

<p>
|&gt; The compiler is also complaining about illegal pointer combinations on
|&gt; calls to the signal function in fbed/execshell.c, lgt/lgt.c, and
|&gt; lgt/execshell.c.
This was resolved similarly in fbed and lgt as follows:

<p>
[in extern.h]
/* Set pre-processor switch for getting signal() handler declarations right.
 */
#if defined(sun) && ! defined(SunOS4)
/* For Suns running older releases, compile with -DSunOS4=0 to suppress
        bogus warning messages. */
#define SunOS4  1
#endif
#if __STDC__ || (defined(SYSV) && ! defined(cray)) || SunOS4
#define STD_SIGNAL_DECLS 1
#else
#define STD_SIGNAL_DECLS 0
#endif

<p>
[Then whenever signal handlers are declared:]
#if STD_SIGNAL_DECLS
STATIC void general_Handler();
#else
STATIC int general_Handler();
#endif

<p>
[And, where they are defined:]
#if STD_SIGNAL_DECLS
STATIC void
#else
STATIC int
#endif
general_Handler( sig )
int sig;

<p>
[Finally, the return from each handler:]

<p>
#if STD_SIGNAL_DECLS
        return;
#else
        return sig;
#endif

<p>
|&gt; Enjoy,
|&gt;
|&gt; Dick
I already have. :-{
Thanks for the detailed bug reports.

<p>
-Gary
Date:     Wed, 12 Jun 91 7:04:23 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  CAKE Fixed

<p>
This evening, I fixed CAKE so that internally, a number of subroutines no
longer return a union Wait, but instead return an integer.

<p>
It seems that /bin/cc on UNICOS 5.1 has some difficulty with this construct,
and this is the reason that CAKE has not worked on Eglin's YMP.
	Best,
	 -Mike
Date:     Thu, 13 Jun 91 8:03:58 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  VDECK & Geom Export

<p>
Over the last few evenings, I have modified the VDECK program to
use the new LIBRT geometry import/export interface.

<p>
As a result, the new VDECK in Release 4.0 will be able to handle nearly
all MGED models, except for those where non-GIFT primitives (like NURBS
and NMGs) have been used. This includes booleans above the region
combinations (like tank minus cutaway), groups within regions, regions
subtracted from (or intersected with) other regions, etc., courtesy of
using the new tree-walker. I have also extended it to be able to output
HAF and ARBN solids. For builders of enormous models, all limits on
number of solids have been removed. I'm certain these improvements will
thrill the folks at ERIM, and others who may still use GIFT.

<p>
If you have a GIFT deck, you can use COMGEOM-G to convert it to a .g file,
and then use VDECK to get back an equivalent GIFT deck.  I have run several
models back and forth.  This was a good way to catch bugs in the libraries.

<p>
For me, the object of the exercise was to demonstrate that new
subroutines for geometry export work, and are easy to use.  VDECK is now
a prime example of this.  The new VDECK source code makes no reference
to db.h (the on-disk format of geometry) at all, so it has no dependence
on the peculiarities of how solids are stored on disk.  This means that
the import/export routines succeed at providing a loss-less interface to
the full MGED database, with much less pain & effort than reading the
database yourself. It also means that VDECK will be unaffected by
database format changes.

<p>
This new version of VDECK could be easily modified, for example, to
provide an IGES Solids file (for that set of solids that the systems
have in common), or for other CSG-capable systems.

<p>
	Onwards!
	 -Mike
Date:     Fri, 14 Jun 91 2:03:58 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Release 4.0 schedule etc

<p>
Jim -

<p>
Thanks for the kind words.  Here is the schedule of events leading up
to Release 4.0:

<p>
Mon June 24             (Features Freeze for BRL-CAD Release)
Mon July 1              (Begin VLD-only "alpha" test of Release 4)
Tue July 9              (Begin "beta" tests of Release 4)
Mon July 22             (Planned date to have finalized Release 4)

<p>
It is important to be very careful when mixing programs from the
experimental Release 4.0 software and the current production Release 3.7
software.  In particular, .g files created or edited with Release 4.0
software may not work with the old Release 3.7 software.  There are lots
of new goodies in the .g file that didn't exist in 3.7 days.
So, there is "upwards compatability" (all 3.7 databases work on 4.0),
but not "backwards compatability" (4.0 databases will NOT work on 3.7).

<p>
So, feel free to experiment, but please be careful, and do it on a
copy of your precious files, rather than on your original!

<p>
	Best,
	 -Mike
Date:     Fri, 14 Jun 91 7:03:11 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  LIBRT identity matricies

<p>
My project for this evening was to act on a suggestion made by Harry Reed.
As you may recall, Harry builds very large MGED databases, and he uses
very few modeling transformations.  (He prefers to simply transform the
solids).

<p>
Harry noted one day that a 4x4 transformation matrix consumes 128 bytes
of memory, and if he has 30,000 solids with identity transformations,
that is 3.8 Mbytes of memory that could be saved.

<p>
I modified LIBRT's "struct soltab" so that mat_t st_pathmat has become
matp_t st_matp.  A null pointer denotes an identity matrix, and non-
identities matricies are malloc()ed as required.  As a byproduct,
this change also makes the "prep" phase go a little faster, too.

<p>
	Best,
	-Mike
Date:     Fri, 14 Jun 91 8:46:37 EDT
From:     Paul Tanenbaum &lt;pjt@BRL.MIL&gt;
Subject:  ADC Command added to MGED(1)

<p>

<p>
     I've just installed a command which allows keyboard control
of the angle/distance cursor.  It has the following synopsis:

<p>
        adc             toggles display of angle/distance cursor
        adc a1 #        sets angle1 (degrees)
        adc a2 #        sets angle2 (degrees)
        adc x #         sets horz. coord of cursor location (local units)
        adc y #         sets vert. coord of cursor location (local units)
        adc dst #       sets tick distance (local units)
        adc reset       Resets angles, location, and tick distance.

<p>
You will see it in release 4.0.
     +++paul

<p>
Date:     Fri, 14 Jun 91 13:33:32 EDT
From:     "John R. Anderson" (VLD/ASB) &lt;jra@BRL.MIL&gt;
Subject:  IGES-to-BRLCAD Translator

<p>

<p>
     Thanks to some help from Mr. Muuss, the  IGES-to-BRLCAD
translator  (iges-g)  that  I reported on at the last BRLCAD
Symposium will be included in the upcoming release 4.0. Here
is a brief description of its capabilities:

<p>
     Iges-g converts IGES files (ASCII  format)  to  BRL-CAD
database  format.   The  IGES file is expected to conform to
the ANSI standard, ASME Y14.26M-1989,  which  is  esentially
IGES  4.0.  All  IGES  CSG  objects  are converted to BRLCAD
equivalents. Most conversions are exact, with the exceptions
of  the  solid  of revolution and the solid of linear extru-
sion. These solids do not exist in BRL-CAD and are therefore
approximated. The solid of revolution is built from a series
of truncated right  cones  developed  by  approximating  the
curve  to  be  revolved with a series of straight line sege-
ments. The extrusion is similarly handled  by  approximating
the  curve  to  be  extruded with straight line segments and
using that to build a BRL-CAD polysolid.

<p>
     IGES non-uniform rational B-spline surfaces (NURBS) are
also  converted, but this translator is not intended to be a
BREP translator at this time. All NURBS are combined into  a
single BRLCAD spline solid named "nurb.s".

<p>
     An all-encompassing group is  created,  with  the  name
"all",  that  includes  all  the objects in the database not
referenced by other objects.

<p>
     I hope this proves useful to some of you.

<p>
				-John

<p>
Date:     Fri, 7 Jun 91 15:12:51 EDT
From:     "Jill H. Smith" &lt;jill@BRL.MIL&gt;
Subject:  TAP Report

<p>
                         BRL-CAD Release 4.0

<p>
BRL-CAD, Release 4.0, is in the final testing phase and will  soon  be
available  for  distribution.   BRL-CAD  is a government developed and
owned geometric modeling software  package.   This  package  uses  the
Constructive  Solid Geometry (CSG) technique where desired volumes are
created by combining basic primitive solids with  boolean  operations.
This  long  awaited release will contain numerous improvements and new
capabilities, the most significant being the  addition  of  n-Manifold
Geometry  (NMG)  support.   NMG  is  a  polygonal  (faceted) geometric
representation, but unlike other polygon  based  systems  stores  full
topological  as  well  as  geometric information.  This means that the
relationships between all NMG  elements  are  continuously  available,
making  it  possible  to  robustly apply booleans to the NMG polygons.
With NMGs, BRL-CAD now has full polygonal support,  allowing  for  the
import  of  other  polygon based geometries.  Furthermore, through the
tessellation and boolean routines, the  current  primitive  based  CSG
geometry  of  BRL-CAD  models  can  readily be converted for export to
polygon based modelers.  Finally, the NMG polygons will allow for full
exploitation   of   the   fast   polygon   fill  available  on  modern
workstations, giving real time shaded display capability for  enhanced
visualization.   Other  additions  to Release 4.0 include a completely
new spline library and new primitive solids(arbitrary  convex  faceted
solid-ARBN,  the  halfspace-HAF, and wire solids-WIR).  There also are
improvements in other areas such as  the  data  base  converters,  the
network  distributed  ray-tracing  software,  and the frame buffer and
ray-trace libraries. POC: Keith Applin, X6647

<p>

<p>

<p>
INPUT PREPARATION FOR PREDICTIVE THERMAL MODELING INCLUDED IN BRL-CAD

<p>
IRPREP is a collection of C-programs for extracting geometric and
material properties from BRL-CAD MGED solids models for input into
predictive thermal modeling codes.  One can also generate a correctly
formatted input file for PRISM ( Physically Reasonable Infrared
Signature Model), a code from the Keweenaw Research Center.  These
programs, written by Susan Coates and developed through efforts of the
VLD/ VMB/Signatures Team and the SECAD/WSTB/IR System Technology Team,
determine region volumes, centroids, free and shared surface areas,
adjacent region pairs,  conduction factors, and shape factors.

<p>
Each region of an MGED description functions as a node in the
lumped-parameter mesh for PRISM.  Region volumes, used to determine
thermal masses, and region centroids, used in calculation of conduction
factors, are calculated from information gathered by dense parallel ray
sampling of the geometry.  The same ray-trace information is used in
calculating the areas for surfaces that bound air (free) and that are
shared by other regions. Conduction factors are determined from a
user-selected conduction path length function in combination with shared
surface area and adjacent region pair material properties.

<p>
The shape factor from region A to region B the fraction of all lines
leaving the surface of region A that have line of sight to region B.
IRPREP determines the shape factors for a set of regions by means of
Monte Carlo sampling. The shape factors are currently used in modeling
the radiative exchange taking place in an engine compartment.

<p>
IRPREP will be released in the upcoming 4.0 Release of the BRL-CAD package.
POC: Edwin Davisson, Ext. 6711

<p>

<p>
Date:     Sun, 23 Jun 91 1:53:33 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  "brlman"

<p>
For those systems that install BRL-CAD and don't have NROFF or DWB,
the "brlman" command should solve the problem.  It is a simple
shell script which uses Henry Spencer's AWF "nroff -man" formatter.

<p>
brlman honors the MANPATH, PAGER, and MANPAGER environment variables,
using "more" by default.

<p>
This means that recipients of the CAD package will always be able to
reference the on-line manual pages.

<p>
	Best,
	 -Mike
Date:     Mon, 1 Jul 91 14:08:19 EDT
From:     Susan Muuss (VLD/ASB) &lt;sue@BRL.MIL&gt;
Subject:  Cell Plot overlays

<p>
I am pleased to announce that BRL-CAD now has the ability to do quick cell-plot
overlays.  Cell-fb now has a logging option which prints out information
which is used by rtregis (a program that constructs a registration matrix
for use by plrot) to register an RT produced hidden line removed plot file
with the cell-plot.

<p>
This is a major break-through since it permits a cell-plot and an rthide
UnixPlot file to be registered and overlayed within seconds.  All the
programs necessary to achieve this will be in the next BRL-CAD release, so
enjoy.

<p>
			Cheers,

<p>
				Sue
Date:     Tue, 2 Jul 91 14:16:55 EDT
From:     Susan Coates (VLD) &lt;scoates@BRL.MIL&gt;
Subject:  BRL-CAD 4.0 alpha test

<p>

<p>

<p>
I am running into a problem in compiling a program I am writing
(stick.c).  It is using libwdb.  I have been compiling it using
the following statement and it has worked fine.

<p>
  cc stick.c /usr/brlcad/lib/libwdb.a -lm -o stick

<p>
This did not work after I started using the new cad distribution.
When I used libwdb.a.bak it worked fine.  See the script below.
My file is on /n/walrus/s/scoates/IR.prep.stick.

<p>

<p>
	$ cc stick.c /usr/brlcad/lib/libwdb.a -lm -o stick
	/usr/bin/ld:
	Undefined:
	mat_vec_ortho
	rt_functab
	rt_log
	db_free_external
	rt_bomb
	rt_identify_magic
	rt_units_conversion
	$
	$ cc stick.c /usr/brlcad/lib/libwdb.a.bak -lm -o stick
	$

<p>

<p>

<p>
Why do I get all these things that are undefined?

<p>
If you need more information please let me know.

<p>
                                         Sue

<p>
Date:     Tue, 2 Jul 91 14:36:41 EDT
From:     Paul Stay &lt;stay@BRL.MIL&gt;
Subject:  Re:  BRL-CAD 4.0 alpha test

<p>
Sue-

<p>
The problem is that you need to include two more libraries with the
libwdb now.  libwdb now depends on routines that
are found in librt, another system library must also be included on
the SGI machines -lmpc. The following command worked fine.

<p>
cc stick.c /usr/brlcad/lib/libwdb.a /usr/brlcad/lib/librt.a -lmpc -lm -o stick

<p>
-Paul

<p>
Date:     Tue, 2 Jul 91 15:50:44 EDT
From:     "Gary S. Moss" (VLD/VMB) &lt;moss@BRL.MIL&gt;
Subject:  Lgt fixed for 3.10.

<p>
Mike,
	Lgt did not initialize the res_model semaphore, so it was dumping
core in librt/tree.c:rt_find_identical_solid() where it calls RES_ACQUIRE
on that semaphore.  If you haven't already mentioned this new semaphore in
the release notes, it would be a good idea.  I updated lgt sources on wolf
and the binary on walrus.

<p>
	Interestingly, the RCS archive on wolf for lgt/do_options.c was
corrupted;  it yields a truncated file (with a couple of lines of garbage
at the end),  so I copied the archive to do_options.c,v.bad and made a
new archive from a copy I had elsewhere.

<p>
	Another change that I noticed in compiling a non-BRLCAD application
with 3.10 was that the re_seg field of the resource struct was changed to
a "struct seg" from a "struct seg *" and that the SEG_NULL macro was
apparently renamed to RT_SEG_NULL.  As it turns out that reference was part
of a workaround that is no longer necessary, so I removed it, but it may
also deserve mention in the release notes.

<p>
-Gary
Date:     Wed, 3 Jul 91 12:51:14 EDT
From:     William Potter (Summer|shenry) &lt;wpotter@BRL.MIL&gt;
Subject:  Window Size

<p>
Why is the new MGED window smaller than the earlier version's window?
Date:     Wed, 3 Jul 91 12:51:14 EDT
From:     William Potter (Summer|shenry) &lt;wpotter@BRL.MIL&gt;
Subject:  Window Size

<p>
Why is the new MGED window smaller than the earlier version's window?
Date:     Wed, 3 Jul 91 14:36:23 EDT
From:     Paul Stay &lt;stay@BRL.MIL&gt;
Subject:  Re:  Window Size

<p>
One of the features of teh new mged is that the window can be resized.
The smaller size is due to the fact that many individuals exressed
a desire to have some space at the bottom of the screen for the
shell window which is used for mged commands. If you want a larger
window you should be able to resize it.

<p>
-Paul
Date:     Sat, 6 Jul 91 1:45:42 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  util & fb split

<p>
The "util" directory in the source tree of the CAD Package has begun to
overflow with utilities.  In order to get the directory size back down
to just barely managable size, I have moved all the Framebuffer (fb)
utilities into their own directory "fb".  There are an appreciable number of
them.

<p>
So, if you don't find the utility you are looking for in "util",
try looking in "fb" as well.

<p>
	Best,
	 -Mike
Date:     Tue, 9 Jul 91 2:28:05 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  Alpha release comments

<p>
Thanks for the detailed comments!

<p>
1)  I fixed the paths command in mged.  utility2.c.  I don't think this was
a new problem, considering the "throw away any input" comment that had
been in the source there.

<p>
2)  I added a warning message to the "keep" command, so that it notifies you
when you are appending to an existing keep file.

<p>
3)  Still thinking about this one.

<p>
4)  Lee has added the same warning message to the "facetize" command.

<p>
5)  "ev" only works for simple cases.

<p>
6)  Using "plot" on a polygon display created with the "ev" command, for
now, gives you a plot of the outlines of the faces.  (i.e., it draws the
edges).  When Phil has time to integrated in his polygon support in
UNIX-plot (next release), then it will output that.

<p>
	Best,
	 -Mike
Date:     Tue, 9 Jul 91 2:30:57 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  Keyboard Lights

<p>
Thanks for the report on the alpha-test software.  There are now 7 function
buttons active on the SGI 4D, and only 4 lights.  In addition, setting
those lights represented a performance problem, as the path from the
computer back to the keyboard (!) is not very fast.  So, in the forthcomming
release, the keyboard lights will not be used.

<p>
	Best,
	 -Mike
Date:     Tue, 9 Jul 91 22:02:27 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  Title in the MGED faceplate

<p>
The title has been removed, to increase drawing efficiency.
Harry Reed correctly noted that all the text on the screen can
noticably slow down the screen drawing rate.
	-Mike
Date:     Thu, 11 Jul 91 0:02:37 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  librt/qmath bug az=90!

<p>
The code in qmath.c for mat2quat was from Ken's 1985 paper.  In his
1989 paper, he gives a different algorithm which looks to be stable
even when w**2 is near zero (i.e., even at azimuth=90 degrees).
I typed it in, as a replacement in librt/qmath.c

<p>
This seems to have solved the problem Sue reported;  hopefully it won't
produce any new problems...
	-Mike
Date:     Mon, 15 Jul 91 22:35:00 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  [Sue Muuss:  [Donald F. Haskell: [Abdul Kiwan: [Abdul Kiwan: TAP report]]]]

<p>
           BRL DEVELOPS IGES-TO-BRLCAD TRANSLATOR

<p>
	At the recent BRLCAD Symposium, John Anderson, Sue Muuss, and
Earl Weaver presented their IGES-to-BRLCAD translator. This software,
being distributed as part of the BRLCAD package, allows the user to
convert files conforming to the Constructive Solid Geometry (CSG)
portion of the Initial Graphics Exchange Specification (IGES) to the
BRLCAD format.  IGES/CSG was recently approved as an ANSI standard and
was preceded by an earlier version that did not include CSG. The earlier
version of the standard was embraced by commercial CAD vendors and
widely implemented. This translator is the first step in a proposed
effort to develop full IGES compatibility for BRLCAD which would include
a BRLCAD-to-IGES translator and extension of the IGES-to-BRLCAD
translator to include Boundary Representation (BREP) IGES files. The
IGES/BREP specification is currently under development and is expected
to become an ANSI standard in the near future. POC: Dr Donald Haskell
Tel (301)-278-2032.

<p>
	    RAPID CREATION OF ANALYSIS CODES USING BRL-CAD/RT
                    VIEW-MODULE INTERFACE

<p>
	On May 7, 1991, Susanne Muuss, of the Air Systems Branch
presented a paper on the 'Rapid Creation of Analysis Codes Using BRL-CAD
The RT View-Module Interface', at the third annual BRL-CAD Symposium.
This paper, which detailed the use and function of the RT view-module
interface, was well received by the attendees and generated much
interest among the audience.  The impact of this software engineering
tool has been significant.  In the few short weeks since the BRL-CAD
Symposium, this software engineering tool has been used by various
software designers to complete three new RT applications: rtweight,
rtrange, rtcell.  Another application is currently under development.
Sue Muuss's presentation is also the basis for an official view-module
template to assist applications programmers with software design and
implementation via the RT view-module interface.  This reception
demonstrates the far-reaching implications this paper has had on
facilitating the design and implementation of RT-based software tools.
POC: Dr Donald Haskell (301)-278-2032.

<p>
   THE AIR SYSTEMS BRANCH TRAINS WEST POINT CADET IN RESEARCH

<p>
	West Point Cadet Frank DeGeorge continued a tradition of
association and exchange between West Point and the BRL - Air Systems
Branch (ASB).  A participant in the United States Military Academy
Summer Research Program, from 3 to 28 June, 1991, Cadet DeGeorge
assisted in development of Height-Velocity damage curves for the HIND-F
helicopter following complete loss of power to one of two engines and
two of two engines.  Cadet DeGeorge was responsible for gathering
helicopter configuration data, calculation of steady level flight trim
states (from hover to maximum forward speed), and determination of
optimal autorotation and landing "flare" states.  In support of the
vulnerability/lethality analysis for Live Fire Test of the M830E1 HEAT
Multi-Purpose Cartridge, Cadet DeGeorge's assistance was essential
to the timely completion of the analysis.  For the past two years the
ASB received West Point Cadets under The United States Military Academy
Summer Research Program. The ASB will continue to participate in this
important research program. POC: Dr Donald Haskell (301)-278-2032.

<p>

<p>
       FEASIBILTY DEMONSTRATED FOR AUTOMATIC SOLID MODELING
                  OF AIRCRAFT AIRFOILS

<p>
	The Air Systems Branch has just completed a feasibility
demonstration for automatically modeling aircraft airfoil shapes that
use the NACA wing section designations.  Heretofore, geometry modelers
produced rough approximations of airfoil surfaces using constructive
solid geometry techniques by combining shapes such as elliptical
cylinders and wedges. Although  these simple airfoil models were
adequate for ballistic vulnerability analyses, they were deficient for
more rigorous analyses such as signature studies.  The automatic
technique exploits the explicit parametric shape specification in the
NACA numbering designations to produce an interpolating spline
approximation that is extremely close to the actual wing shape; indeed
the final spline shape probably more accurately approaches the
theoretical NACA shape than can be effected in metal fabrication by
airframe manufacturers.  The spline shape is then cast into the BRL-CAD
spline solid and thus is compatible with both current BRL-CAD models as
well as new models.  POC is Dr. Donald Haskell, (301) 278-2608.
Date:     Tue, 16 Jul 91 1:56:08 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  MGED window size

<p>
There seems to be quite a debate over the desired initial size of the
MGED window.  Some users want it small, some medium, and some full-screen.

<p>
In this release, it will default to nearly full-screen.

<p>
In the next release, this should be user settable with some sort of
per-user configuration file, perhaps called .mgedrc !
	Best,
	 -Mike
Date:     Tue, 16 Jul 91 14:00:35 EDT
From:     Phil Dykstra &lt;phil@BRL.MIL&gt;
Subject:  Re:  [Mike Muuss: Re: mged]

<p>
A thought: Why not make "title" print out the current title (rather
than the help message) and "title This is a title" set it.

<p>
- Phil
Date:     Thu, 18 Jul 91 13:55:52 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  nirt & librt

<p>
There are two issues:

<p>
1)  Applications that need dynamic memory should use rt_malloc et.al.
everywhere.  It isn't strictly necessary, but it will really foul up
LIBRT's memory debugging, should you enable it with a -x option.

<p>
2)  Applications that need to do I/O **in the parallel sections** should
use rt_log(), or else be careful to protect all that I/O within critical
sections (RES_ACQUIRE/RES_RELEASE).  I/O in non-parallel sections can be
done freely, as you wish.

<p>
I hope this removes some of your concerns, and clarifies the rules.
	Best,
	 -Mike
Date:     Tue, 23 Jul 91 2:55:56 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  pl-tek

<p>
This evening, I got tired of having to RSH to VMB to print unix-plot files,
so I wrote pl-tek, and added it to the UTIL directory.  It seems to work,
and even has a man page.
	-Mike
Date:     Thu, 25 Jul 91 3:23:55 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  cv

<p>
Using Chris' new data format converter routines, I have written
a generalized file converter, "cv", and stuck it in the util/ directory.
It promises to handle a lot of miscellaneous conversion chores for us.

<p>
	-Mike
Date:     Fri, 16 Aug 91 15:38:21 EDT
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
Subject:  Re: cell-fb changes

<p>
Kathy,

<p>
	There was a problem with the "-h" option to the cell-fb command in the
brlcad/bin directory.  I have fixed this, and the new version will go out with
tonight's upgrade to the beta version of BRLCAD.

<p>
Please note that by default, cell-fb "autosizes" the framebuffer to the
smallest framebuffer that will hold the image.  This is why cell-fb prints
the message about fb_size requested/obtained.  This tells you the size (in
framebuffer pixels) of the image being created.  Most of the time, this will
NOT be one of the standard image sizes.  Because of this, the "-a" option on
pix-fb will not be able to get the sizes right.

<p>
To generate a cell plot in one of the standard image sizes, you will have to
specify "-h" or something like "-S 0" on the command line to cell-fb.

<p>

<p>
Lee Butler

<p>
Date:     Sun, 25 Aug 91 3:29:27 EDT
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
Subject:  warning messages from fbclear

<p>
This evening, I changed the notices printed by fbclear:

<p>
 fbclear: NOTE: non-linear colormap in effect.  -c flag can correct this.
 fbclear:  NOTE: framebuffer is zoomed.  -c can correct this.

<p>
For the novice user the old messages appeared to be warnings about an
UNDESIREABLE condition.  In the case of the colormap, this is generally not
the case.  Non-linear colormaps are used to gamma-correct framebuffers.
For each message, I have selected more "neutral" language:

<p>
 fbclear: NOTE: non-linear colormap in effect.  -c flag loads linear colormap.
 fbclear:  NOTE: framebuffer is zoomed.  -c will un-zoom.

<p>
Lee
Date:     Wed, 28 Aug 91 4:41:32 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  mged 4.0 feature

<p>
In response to some of the numerous suggestions from Ed Davission and
his team, Lee and I have added a last-minute feature to mged:  the
.mgedrc file, which mged reads and processes before starting interactive
editing sessions.  .mgedrc files contain commands just like you would
type at the keyboard.

<p>
We are presently experimenting with ways that this can become useful,
most notably in the areas of the autosize feature, and (SGI-specific)
variables to control size and placement of the window on the screen.

<p>
There isn't time to expand this into a rich facility, but this should
address the most serious issues of mged mode setting, and provide a good
mechanism for future additions.

<p>
	Best,
	 -Mike
Date:     Fri, 30 Aug 91 9:13:07 EDT
From:     Paul Tanenbaum &lt;pjt@BRL.MIL&gt;
Subject:  NIRT(1) enhancement

<p>

<p>
     I added twelve new "output items" to NIRT.  A highly placed
ACST official stated (not for attribution) that it probably wouldn't
break the 4.0-distribution process to do so.  Anyway, NIRT can now
tell you the components of the entry and exit normals both in model
and view coordinates.  The new item names are of the form:

<p>
		    nm_&lt;var&gt;_&lt;loc&gt;

<p>
where &lt;var&gt; is an element of

<p>
	    {"x", "y", "z", "d", "h", "v"}

<p>
and &lt;loc&gt; is in

<p>
		    {"in", "out"}.

<p>
Of course, nirt.1 has been updated accordingly.
     +++paul

<p>
Date:     Sat, 31 Aug 91 3:43:41 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Stardent port

<p>
Thanks to Phil Dykstra and John Grosh kindly providing me with network
access to a Stardent VISTRA 800 workstation, BRL-CAD has been ported
to it.  Both network and X11 framebuffers work, and MGED superficially
seems to work via X11.  Anyway, if someone gets serious about this
machine, there probably isn't much work left to do.

<p>
This was a good effort, because the Stardent C compiler, when run in ANSI
C mode, gave a lot of useful warnings.  There was one mged file that
caused an internal compiler error, but some code simplification fixed that.

<p>
In the process, I also ported JOVE to the Stardent and IBM RS/6000,
which will be quite handy to have around.
	Best,
	 -Mike
Date:     Sat, 31 Aug 91 7:13:25 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  BRLCAD 4.0beta librt bug.

<p>
Gary -

<p>
Thanks for once again providing an excellent test case.  I really
appreciate having a reproducable starting point to work from! I was able
to duplicate the effects that you noted, and spent much of the evening
trying to make sense of what was going on.  A valuable byproduct was
that DEBUG_PARTITION output of librt is now even better than before.

<p>
The differences between 3.7 and the beta version of 4.0 are due entirely
to the fact that, in the absence of a user-provided overlap handler,
librt simply makes a random choice as to which region will claim the
region of space that has the overlap.  For lots of reasons, the
randomness in 3.7 and 4.0 is not the same, and that explains the
different results.  In the test case you provided, solid "s1" in
region "hull.armor/r1.top" overlaps all the other regions involved.
I have a sketch of the situation on my desk, if you would like to see it.

<p>
While studying the output, it struck me that it might be nice if the
default overlap handler made more of an effort to provide some
consistency in the face of overlaps.  So, I extended the return codes
from a_overlap(), to allow the overlap handler not only to indicate
accept/reject as before, but also to indicate WHICH of the two regions
to accept.  This now nicely separates policy (provided by the user) from
the mechanism (still implemented by librt) of handling overlaps.
The default overlap handler has several new heuristics to try and
make more consistent choices, which in at least some cases seems
to be the right thing to do.

<p>
In the case of your example:

<p>
	rtshot -x 2000 -p 4000 -36 0 -d -1 0 0 ktank.g component

<p>
release 3.7 broke the ray into 10 different partitions, while 4.0
of Friday morning broke the ray into 12.  The latest version leaves the
ray intact as a single partition:

<p>
--- Hit region /component/hull/hull.ext/hull.armor/r1.top (in s1, out s1)
  InHIT dist=1841 (surf 0)
    Point (2159, -36, 0)
    Normal (1, 0, 0)
    PDir (0, 0, -1) c1=0, c2=0
 OutHIT dist=7175 (surf 1)
    Point (-3175, -36, 0)
    Normal (-1, 0, 0)

<p>
which in this case seems to be a reasonable thing to do, since "everything
else" overlaps with r1.top.

<p>
RIP does not need to be changed to continue working.  However, if RIP is
to take advantage of the new heuristics, then RIP's f_Overlap() routine
will need to be modified slightly, so as to express more of a choice
than it's present return(1).  Here is how librt's default handler works:

<p>

<p>
/*
 *  Default handler for overlaps in rt_boolfinal().
 *  Returns -
 *	 0	to eliminate partition with overlap entirely
 *	 1	to retain partition in output list, claimed by reg1
 *	 2	to retain partition in output list, claimed by reg2
 */
int
rt_defoverlap( ap, pp, reg1, reg2, pheadp )
register struct application	*ap;
register struct partition	*pp;
struct region			*reg1;
struct region			*reg2;
struct partition		*pheadp;
{
	.......
	/*
	 *  Apply heuristics as to which region should claim partition.
	 */
	if( reg1-&gt;reg_aircode != 0 )  {
		/* reg1 was air, replace with reg2 */
		return 2;
	}
	if( pp-&gt;pt_back != pheadp ) {
		/* Repeat a prev region, if that is a choice */
		if( pp-&gt;pt_back-&gt;pt_regionp == reg1 )
			return 1;
		if( pp-&gt;pt_back-&gt;pt_regionp == reg2 )
			return 2;
	}
	/* To provide some consistency from ray to ray, use lowest bit # */
	if( reg1-&gt;reg_bit &lt; reg2-&gt;reg_bit )
		return 1;
	return 2;
}

<p>
If you can suggest further refinements, I'd love to hear them!

<p>
I hope that this analysis puts your worries to rest about the differences
between 3.7 and 4.0, and will leave you free to resume RIPing away.

<p>
	Best,
	 -Mike

<p>
Date:     Tue, 17 Sep 91 18:51:27 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  Brlcad4.0

<p>
Dear Holly -

<p>
In your message, you indicated:

<p>
&gt;&gt;         I have been informed by Sue Coates that there is
&gt;&gt; some problem with the include file for this function. I
&gt;&gt; statically declare the 'struct application ' variable I
&gt;&gt; use and assign it specific values.
&gt;&gt;
&gt;&gt;         Could someone please elaborate on the problems
&gt;&gt; and provide me a list of possible solutions or at least
&gt;&gt; some explainations???
&gt;&gt;

<p>
I am not aware of any problems with the header file raytrace.h,
in which rt_shootray() and struct application are defined.

<p>
When you file a bug report, it would be most helpful if you would
provide the name of the file that has the source code in it which
is troubling you.  Without more information to go on, I can't be
certain what the issues might be.

<p>
If you are attempting to initialize the application structure at
compile time, that won't work from version to version.  Here is
the comment in the header file:

<p>

<p>
/*
 *  This structure is the only parameter to rt_shootray().
 *  The entire structure should be zeroed (e.g. by bzero() ) before it
 *  is used the first time.
 ...
 *
 *  Note that the organization of this structure, and the details of
 *  the non-mandatory elements are subject to change in every release.
 *  Therefore, rather than using compile-time structure initialization,
 *  you should create a zeroed-out structure, and then assign the intended
 *  values at runtime.  A zeroed structure can be obtained at compile
 *  time with "static const struct application zero_ap;", or at run time
 *  by using "bzero( (char *)ap, sizeof(struct application) );" or
 *  rt_calloc( 1, sizeof(struct application), "application" );
 *  While this practice may not work on machines where "all bits off"
 *  does not signify a floating point zero, BRL-CAD does not support any
 *  such machines, so this is a moot issue.
 */
struct application  {
	/* THESE ELEMENTS ARE MANDATORY */
	struct xray	a_ray;		/* Actual ray to be shot */
	int		(*a_hit)();	/* called when shot hits model */
	int		(*a_miss)();	/* called when shot misses */
	int		a_onehit;	/* flag to stop on first hit */
	struct rt_i	*a_rt_i;	/* this librt instance */
	int		a_zero1;	/* must be zero (sanity check) */
	/* THESE ELEMENTS ARE USED BY THE LIBRARY, BUT MAY BE LEFT ZERO */
....
	/* THE FOLLOWING ELEMENTS ARE MAINLINE & APPLICATION SPECIFIC. */
	/* THEY ARE NEVER EXAMINED BY THE LIBRARY. */
....
};

<p>
If this relates to your difficulty, I would be happy to provide you
with copies of some E-mail traffic that discuss this programming
strategy. Or, if you could provide me with a pointer to your source code
and a test case, I'll make sure that your difficulty gets looked at
and resolved.

<p>
Continued discussion of this should be directed just to &lt;acst&gt;, so that
we are not cluttering the mailboxes of the whole Division, e.g. &lt;vld&gt;.

<p>
	Best,
	 -Mike

<p>
Date:     Thu, 19 Sep 91 16:32:38 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  g2asc update

<p>
Thanks for your note a week or two ago, reporting that the TACOM "FRED"
program was not able to read new format .asc file.  I have modified the
g2asc program to output a compatible value for the c_length field,
so when the next CAD update goes out, things should work better.

<p>
This should also make it possible to move .asc files back to machines
running Release 3.7, should that be necessary.

<p>
I would appreciate hearing about any other incompatibilties that you
might encounter.

<p>
	Best,
	 -Mike
Date:     Fri, 20 Sep 91 16:13:05 EDT
From:     Mike Muuss &lt;mike@BRL.MIL&gt;
Subject:  Re:  area command in MGED

<p>
Thanks for your bug report of 6-Aug.  The problem you reported
(boundp and parea not being included in the distribution)
has been rectified in the 4.0 Release of BRL-CAD.

<p>
Thanks for pointing this out.
	Best,
	 -Mike
Date:     Fri, 20 Sep 91 19:50:52 EDT
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
Subject:  Re: Angle Distance Cursor in MGED

<p>
Jim,

<p>
	Thanks for the note.  It is clear that different folks wanted
different things from the ADC.  In the next release (Beta/final?) the ADC
ABSOLUTE position will be reported as "cent=(x, y)" and the RELATIVE position
(which was what was previously reported as "cent=") will be reported as
"delta=(x, y)".

<p>
Lee Butler
Date:     Mon, 15 Jul 91 17:48:48 EDT
From:     "Lee A. Butler" &lt;butler@BRL.MIL&gt;
Subject:  Size of BRLCAD 4.0

<p>
Many of us have noticed that BRLCAD 4.0beta requires substantially more disk
space than 3.7.  In some cases, utilities have more than doubled in size.
I went looking for the reasons for this today.  It would appear that the
greatest difference comes from the fact that the SGI now links with the X11
libarary.  This is somewhat compounded by the fact that we are not currently
using a shared library for X11.

<p>
As an example, I compiled libfb(3) and fbcolor(1) with and without the X11
support.  Here is the breakdown:

<p>
		  Size	  file		coments
		----------------------------------------
		 293760  fbcolor*	No X11
		 818432  fbcolor.X11*	X11 support

<p>
Lee A. Butler
SLCBR-VL-V					Internet: butler@brl.mil
Ballistic Research Laboratory			   Phone: (301) 278-9200
Aberdeen Proving Ground, MD 21005-5066
Date:     Mon, 23 Sep 91 2:13:00 EDT
From:     Mike Muuss  &lt;mike@brl&gt;
Subject:  Re:  BRL-CAD Release

<p>
Dear Sue -

<p>
In your note of Mon, 29 Jul, you mentioned an interesting problem:

<p>
&gt;&gt; I have noticed that with the new release of mged there is no limit
&gt;&gt; (or a much larger limit) on how many regions I can display by typing
&gt;&gt; e r.b*.  This is really nice.  However, there is still a limit on
&gt;&gt; the number of regions that rt can handle.  The following lines show
&gt;&gt; what I typed and the errors I got.
&gt;&gt;
&gt;&gt;         e r.b*     (This displays approximately 1610 regions.)
&gt;&gt;         rt -s 1024 -P 4
&gt;&gt;         rt:  Arg list too long Abnormal exit x 1000, return (exit) code=16
&gt;&gt;
&gt;&gt; I got around this by grouping all my regions into one group (g cylinders
&gt;&gt; r.b*).

<p>
I investigated this behavior this evening.  The "rt" command in MGED
currently has a limit of 2000 objects.  However, the SGI operating system
has a limit (called ARG_MAX) on the number of *characters* permitted when
exec'ing a new program (the "command line" to the program).  This limit
is set by SGI at 5120 characters, and in this case, is the limit that
you were running into.  There isn't much that can be done about this,
so your work-around is a good general practice.

<p>
	Best,
	 -Mike
<hr>
<a href="mailto:mike@arl.mil">
  &lt;<em> mike@arl.mil </em>&gt;
  </a>

<br>
<a href="index.html"> Release notes for other versions of BRL-CAD </a>
</body>
